On Thu, Oct 16, 2014 at 01:20:54PM +0200, Matthias Urlichs wrote: > Florian Lohoff: > > is it intentional that gnome is removed when systemd is replaced by sysvinit-core? > > Please always retry this kind of thing with aptitude, and try to let it > choose alternate resolutions to the dependency chains. > > 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. 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. Beside that with every alternative you choose a non-default package for you move further into "here be dragons" land so that should really not be the first suggestion if it can be avoided. A user who on the other hand already knows what he wants has a multitude of options to express his needs/requirements, it is just a matter of how to do it properly… I shouldn't be the one advising against using any aptitude option, because I have no experience with it, but I have enough dependency resolver experience to be able to say that optimising along less removes is very dangerous: Apart from the lsb-invalid-mta example mentioned above, such a setting has no problem with removing essential packages (remember, close to nothing has a positive dependency on it) and aptitude not even has a scary warning for it. I think you should know that before its removing dpkg on your next dist-upgrade (okay, it will not be dpkg, too many positive dependencies for that for now). So act like the chosen configfile name suggests and read the manual, aptitude has one and it documents these kind of things for a reason… If that isn't enough motivation to read it already, let me tell you that the suggested setting isn't even helping in the scenario you described as you optimize for priority first… In terms of the "I don't want package X" problem class its easiest to simply tell the package manager that this is the case. Negative pins and action modifiers on the commandline come to mind. The "don't be an idiot" problem is a bit harder. I actually like apt-get for being so simple minded as it means I can "easily" follow its thought process. The problem with removes is that we tend to bundle a big bunch of different cases into the same group ranging from "these two packages can no longer co-exist; choose wisely as you will loose functionality" all the way down to "this is a transitional package nobody will miss". If you have a clever idea how to solve this, I am all ears… Moo, David Kalnischkies
Attachment:
signature.asc
Description: Digital signature