View Single Post
Estel's Avatar
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#9
Originally Posted by sixwheeledbeast View Post
OK.
Take fCamera 1.0.5-2 for example, it should conflict with kernel power, it does in HAM; all is well.
However, on both FAM and apt it doesn't conflict and allows installation, in most cases this causes a boot loop.
Thanks a lot for example. Could you explain what causes the bootloop? I tried to reproduce it, but couldn't get into loophole (sic!)

Originally Posted by sixwheeledbeast View Post
I believe there are other examples of this dependency mess all over Maemo, apt doesn't notice these conflicts and if apt doesn't FAM can't either.
This is a good point,m but I'm wondering... If Maemo's packaging rules are so FCKD, that apt-get (and it's frontends) can install things propelling us into bootloop - and only some obscure (from upstream point of view) package manager HAM, can detect those problems - maybe we should fix our repo systems, then?

What exactly is the difference causing such mess? What "flag" (or whatever) HAM recognizes, that apt-get doesn't and why the hell we need to depend on obscurity of HAM?

Originally Posted by sixwheeledbeast View Post
Why waste my time when HAM works?
Because, AIUI, main goal of future for Maemo (FreEmantle) - in this or any other, hypothetical device - seems to be "more upstream, less obscure things that doesn't work anywhere else".

Originally Posted by sixwheeledbeast View Post
Another example with screenshots attached below.
HAM shows one thing and FAM shows something else, this is the same system, both managers updated. I know which manager I trust to do the upgrade!
I don't understand this example. Have you dissected what is wrong? Why apt-get doesn't show upgrade for bander, and HAM does? I'm using the same programs, and never run into such weirdo, using apt (via frontend or not).

Unlike you, in this case, I would stop trusting whole Maemo repos, instead of trusting obscure (against, as no offense to HAM - it's just obscure from GNU/Linux point of view), custom package manager.

Originally Posted by sixwheeledbeast View Post
It's also very easy to install packages you shouldn't from different sections like libs for example. One without knowledge could easily end up in a mess. Only user packages should be available.
I strongly disagree here - I think it should be up to user's settings. BTW, in FAM, you don't "see" libs by default, too - you need to explicitly choose "ALL SECTIONS _ ADNACED!" for that.

Originally Posted by sixwheeledbeast View Post
The option is checked as default FFS. Anybody can install this package and use it (it's in extras BTW). I wouldn't expect a complete newbie to be able to get root and use autoremove without understanding it. I could expect someone finding FAM in the repos and using it without knowing what the options actually do.
I agree that autoremove shouldn't be checked by default after installation. Sadly, despite that everyone is mentioning it for years, no one actually took the effort to change this (one liner, as I presume) in the FAM sources and upload fixed version to repos.

Personally, I haven't done it, as I don't see a problem with unchecking it after install (but still, I agree, that most elegant way would be to have it disabled by default).

Originally Posted by handaxe View Post
I don't believe Estel was implying what you present. I think rather, he was wanting to say (yes, his word choice occasionally tends to the lurid) is until now, few if any have bothered to detail the issues, and so the naysayers seem just that.
Thanks for being devil's advocate Indeed, it is *exactly* what I meant. BTW, huge thanks to sixwheeledbeast for providing meaningful examples, AFAIK for the very first time in TMO.

/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!