2010/5/28 Stephen Leake <stephen_le...@stephe-leake.org>: > Ludovic Brenta <ludo...@ludovic-brenta.org> writes: > >> Stephen Leake wrote: >>> Ludovic Brenta <ludo...@ludovic-brenta.org> writes: >>>> The reason for all this is that when a package libX2-dev Conflicts: >> with >>>> and Replaces: a package libX1-dev, aptitude does not remove libX1-dev >>>> and install libX2-dev; instead, it marks libX1-dev as broken and leaves >>>> libX2-dev uninstalled. >>> >>> This seems like a clear bug in aptitude.
This seems like a bug in your understanding, not in apt(itude). The name libX1-dev suggests that it can be co-installed with libX2-dev and co as otherwise the version number wouldn't make much sense (yeah i know, in a few other cases… i said not much) - automatic updates in which libX1-dev is killed for good by libX2-dev is absolutely not what i would expect as packages will (build-)depend on libX1-dev which obviously can not be satisfied by libX2-dev -- if it could it would be called libX1-dev also or even libX-dev and only the real library is called libX2 … 2010/5/28 Stephen Leake <stephen_le...@stephe-leake.org>: > But it seems the best way to reduce the annoyance is to improve aptitude > (or dpkg). Add an option that says "treat Replaces as the correct > upgrade path". Or add a new control field Upgrades for that purpose. Replaces form the correct upgrade path? I really thing Depends form the upgrade path - and all the negative ones just make it more complicated. ;) (or more serious: give additional hints) Negative Dependencies have a serious problem: A package manager can choose to retreat from upgrading a package because it would e.g. break to much - and that is in your interest! But do not only shoot into the dark, each manager has debugoptions to show you why it does certain things. Looking at these decisions can help a lot in understand how to express dependencies ((pre)depends, recommends, suggests, replaces, conflicts, provides, breaks, …) correctly (or it will lead you into insanity, depending on how pain resistant you are ;) ). > However, my reading of Debian policy gave me the impression that > Replaces was supposed to be used for that purpose. Since the tools > currently do not fully support that use, I think they are broken. No. Replaces is used to say to dpkg: It is okay that this package overrides files of the other package - otherwise dpkg would complain loudly for good reasons. It doesn't say something about the upgrade path. It also does not say that B will replaces A completely - this is maybe the case, maybe not (it replaces only a single file). Provides give the indication that B is a complete replacement for A, but in this case you should be sure that it is really a complete replacement. libX2-dev can't provide libX1-dev for example - or it could but only if all packages which work with libX1-dev can be built without a change with libX2-dev instead of libX1-dev. This also eliminates the idea to let libX1-dev be a dummy package only depending on libX2-dev as the packages building against libX1-dev will be (completely) broken. This is normally done for Package renames and described in e.g. http://wiki.debian.org/Renaming_a_Package Method B will in future (squeeze+1) take care of these dummy empty packages if the maintainer does it correct. Until then we need to handle them with autoremove and co - which is yet another "interesting" and complicated problem… So i would recommend to describe more what you actually want and your specific problem so people can help you (maybe the questions are a better fit in d-mentors) and not what you think is a bug in a package manager - if it is really a bug it should be expressed with a proper bugreport against the package manager in question… Best regards, David Kalnischkies (Debian APT GSoC student) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik96wdwal1imqqkm_fzkqyfb0vnsdnb6ywmp...@mail.gmail.com
