On Sun, Oct 19, 2014 at 09:32:54AM +0200, Matthias Urlichs wrote: > David Kalnischkies: > > > Apitude, too, *really* likes to choose 500 deletions rather than upgrading > > > even a single package to a version with slightly-lower priority (as > > > defined > > > in /etc/apt/pref*), but at least you can tell it to try harder. :-/ > > > > I shouldn't, I really shouldn't, but well, I bite… > > > > This isn't trying harder, it is trying increasingly incorrect solutions > > to the problem because aptitude assumes the users is not able to express > > himself correctly. apt-get is treating its user as its god instead, aka: > > user is always right, even if it makes no sense in apt's simple mind. > > > My main problem is that, whenever I install a "difficult" package, the > first solution I get presented is always to simply not install the package > in question. The next 2^n-1 "solutions" transitively remove everything that > currently conflicts with installing the thing in question. Rejecting the > removal of a few core packages then gets me the correct solution, e.g. > upgrading two packages.
I think aptitude is calling this canceling actions. I would bet you can use this config setting to discourage it from doing that, but ultimately its a design choice to allow or forbid them at all. > > Selecting one package in an or-group is a grand example of people not > > understand their tools although the policy is simple and logic: If it > > isn't impossible to let it win, the first alternative wins. If the > > package manager would go for any heuristic based on simplicity of > > installation instead everyone would have lsb-invalid-mta as MTA because > > that is damn easy to install by any standard. Maintainers are very > > heavily relying on this property while e.g. building packages. > > You don't have to drop that part of its logic. Choosing a different package > as a dependency should of course be a "last resort" action (i.e. be heavily > penalized). I'm not talking about changing that. I'm talking about the fact > that aptitude treats upgrading to a slightly-lower-prioritized version of a > package as a *way* worse solution than removing that package (and/or 500 > others). Well, "slightly lower" priority means packages from a different release in general, so that isn't a safe action either. experimental and backports come to mind. Never upgrading to a security fix is another. Also – but that might be a relatively controversial point – users are much better at figuring out which packages they don't want removed compared to e.g. which packages should be held at a lower version, so I can optimize the other values and let the user decide along a property he can easily reason about (I am not suggestion that aptitude or apt-get work that way, but who knows that for sure anyway, right?). > Basically, this boils down to the fact that people shouldn't have to read a > manpage about a complex priority scheme in an equally-complex resolver. > All I want is for aptitude to behave in a sane way by default. > > Its current behavior is not. The usual approach to improving software is to whine about it on mailing lists until its done. While this might work for init systems, it doesn't for most stuff, so the better approach is helping to make it happen. You even made the first step already by realising that the resolver is indeed just as complex as the priority scheme – which can be described in a few sentences. Most people regard them as ancient magic no living human being understands. The irony is that this could very well be a self-fulfilling prophecy as not that many people are left who work on them… (case in point: even with the dirty tricks I pulled to make MultiArch work without too much pain, aptitude with its own solver was still more or less broken by it. I guess I should have done a RoQA while I could… thankfully a small new team materialized out of nowhere later on solving this problem. The history of apt is equally "fun" to look at. We will see when Debian finally run out of luck and does a RoQA ^apt.* I guess…) Anyway, you want to talk about changes to aptitude to someone who is actually into aptitude. aka: ¬me and I doubt you will find such a person in a systemd related thread… Best regards David Kalnischkies
signature.asc
Description: Digital signature
