[Split] ...maybe we should start another thread about package managers
 

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.

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.

To try and reproduce every application installation combination to find a conflict, would take a long time otherwise I would go through every package to prove a point. Why waste my time when HAM works?

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!

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.
Also while mentioning sections, Nokia has disabled the user/hidden packages from being available in apt but they do show in HAM.

FAM uses the --allow-unauthenticated flag for all installs not the most secure method but at least it installs without any unnecessary security prompts :rolleyes:

If you fully understand what is going on you are unlikely to have an issue. However, if your half asleep or forget to check everything with a fine toothcomb there is a possible dependency mess or reflash waiting around the corner.

Just because "you" haven't experienced issues doesn't mean there aren't any.

I take offence to the fact you think I have no right to share my opinion and the fact you imply I would outright lie or jump on a "hate" band wagon.
I have no issues with the developer. He wanted to make a project in Qt and made FAM in the hope it will be useful. He has learned a lot along the way, just like I have, this is the FOSS spirit. Even the great MAG has learned stuff from FAM's sources.
I still believe it would have been better to make something else and provide fixes to HAM via CSSU instead, I am sure others would agree.

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.

Yes, potentially the system has all ready been slightly broken if there's an issue, however, autoremove will just make it worse not better.

Re: [Split] ...maybe we should start another thread about package managers
 

Thanks for cutting/moving that from character map.
And also thanks for clarification/pointing that out.
I did not know that (having FAM installed, but not using it). What I really hate about HAM is it one-action-at-a-time 'slowlyness'. So I am using mainly command line... (thinking I am not affected as having devel repo enabled all the time ;))
ORLY? As a curious cat: could you give an example(s)?

Re: [Split] ...maybe we should start another thread about package managers
 

+1

+1

Yeah, I was also curious about that. But then maybe I missed some hidden feature in HAM as I never touch it due to its complete lack of usability.

Back on the topic of using the CLI and GUI wrappers, Hamster Filer and friends are also just wrappers for ls. But it is much easier/more convenient working in a file manager. The same applies to apt and package managers.

Re: [Split] ...maybe we should start another thread about package managers
 

I've also been using FAM quite a bit, even for CSSU updates in some cases with no adverse effects. Of course, I disabled autoremove in FAM once I discovered it, not that my system has any issues that an autoremove would make worse, but better safe than sorry.

Re: [Split] ...maybe we should start another thread about package managers
 

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.

Re: [Split] ...maybe we should start another thread about package managers
 

FMG has improved HAM immensely - it is faster. Still has it's quirks - presenting updates is one of them, as it often needs to be done twice to see them.

Re: [Split] ...maybe we should start another thread about package managers
 

HAM has red pill mode which allows to see hidden/system packages ;) happily using both but unchecked autoremove as first thing after installing FAM. Also use apt-get, no problems. However FAM did mess my system up one time with the autoremove feature. It was back in the days when I just got my n900 for 1 month (or less)

Re: [Split] ...maybe we should start another thread about package managers
 

whats stopping someone from profiling ham to find the cause of slowness? fmg, as handaxe has stated, has done some work on it but there could be more improvements to be had.

as can be seen by dosbox stuff, i don't mind looking over code but i'm nowhere near the same league as fmg or pali. something as critical as ham i wouldn't want to play with until i get a bit more confident.

Re: [Split] ...maybe we should start another thread about package managers
 

Thanks a lot for example. Could you explain what causes the bootloop? I tried to reproduce it, but couldn't get into loophole (sic!)

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?

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".

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.

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.

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).

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

Re: [Split] ...maybe we should start another thread about package managers
 

Speeding-up HAM is not over(despite I find the version in latest -thumb perfectly usable), it is just that I don't want to make huge changes in such a critical piece of SW like HAM at once. Though I don't think I will touch HAM again before it is included in new CSSU-testing, but that's another story :) .

I don't think it is a rocket science to use oprofile, though the one in repos is too old to be used for thumb-compiled binaries(I use almost newest upstream version and will upload it in extras upon request).

Anyway, there are a couple of things missing in apt-get and FAM compared to HAM:

- system upgrade failure recovery - HAM will try to recover your system in case a reboot/powerdown happens during system upgrade
- "domains" - honestly, I don't want some speedpatch clone to creep on my device because a script-kiddie has pushed it in extras replacing a system package. don't know about FAM, but apt-get will happily install such package.
- "install scripts", etc. - look here if you are curious.

And in addition FAM is unmaintained - the fact that a long standing "bug" like autoremove being checked by default is still not fixed means that this software is not fit for the purpose of being a distribution package manager. IMO.