2010/5/30 Ludovic Brenta <ludo...@ludovic-brenta.org>: > David Kalnischkies <kalnischkies+deb...@gmail.com> writes: >> 2010/5/29 Ludovic Brenta <ludo...@ludovic-brenta.org>: >>> David Kalnischkies <kalnischkies+deb...@gmail.com> writes: >>>> 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. >>> >>> I disagree with this particular part of your analysis. What you say is >>> true of Conflicts, not of Replaces. IMHO, Replaces really, clearly >>> suggests an upgrade path. Why else would the package renaming procedure >>> require both Conflicts and Replaces? >> >> Consider a package A which moved from a bad example-config file to >> a full blown doc translated to 100 languages. The documentation is split >> out into a new package A-doc which will Replaces the old A version >> as it will override the "old" example-file. The A-doc package will end up as >> a Recommends or Suggests for A as it is not strictly needed to work with A. > > This example is wrong.
(I thought of this one while writing it but want to be a bit more generic:) apt currently Replaces manpages-pl because it includes now the polish translation of its manpages itself. Is apt with this Replaces now a valid upgrade path for manpages-pl? Even (or especially) if only manpages-pl is installed on the user system? The Replaces says that if i upgrade apt i should at least try to upgrade manpages-pl before (if it is installed) to get right of the Replaces - it doesn't say that if i have manpages-pl installed i should install apt now as well as it doesn't say that i should install manpages-pl if i have apt installed. If i want that i need a Depends… > The consequence is that, despite the fact that these packages are broken > (without the need for a Breaks: in their successor packages, BTW), > aptitude prefers to leave them installed rather than remove them; this > in turn blocks upgrades. If aptitude hasn't changed its complete logic recently it will behave as apt and will never allow a user to move from a consistent into an inconsistent state, so either your words are misleading, i don't understand you or both. A package is not broken out of a sudden for a package manager. Either the install candidate of another package Breaks it, Conflicts with it or its dependencies in the candidate version are not satisfiable. A in this way "broken" package* is either kept (by not installing the other packages), upgraded (if dependencies allow it) or removed (if installing the other packages is considered more important than the install status of this package) These options are present and a package manager will chose one of those depending on how costly they are. If the remove of package A causes e.g. the remove of thousand other packages it is likely that A will be kept back instead. * It is only broken if the package manager would choose to upgrade regardless of the outcome. Its complete unrelated if the functionality of the package is broken. This can happen, and this need to be modeled with dependencies (Breaks and to a lesser extend Conflicts is what you want) as otherwise the package manager will not know about it. It (=the manager) can't follow rules it doesn't know… > and, of course, Depends: on the exact version of A, i.e. > > Package: A-doc > Depends: A (=2) I hope not as it would be broken for all binary non-maintainer uploads of A… And the Depends is at least questionable even without a version number (many *-doc packages don't depend on anything. And if they do the Depends is completely unrelated or extreme relaxed, only a small subset does it like you suggest it). Give it a try yourself: apt-cache show $(apt-cache search ^.*-doc$ --names-only | cut --delimiter=' ' -f 1 | sort -R | head -n 50) | grep -e 'Package: ' -e 'Depends: ' > Please read the Debian Policy for Ada, to which I provided a link (at > least section 3.2 "Ada Library Information files". I mean it. If you > don't then you cannot possibly understand the problem. I don't know anything about Ada and i don't have read the policy for it as i will not understand it because of that - but even if i would read it it doesn't change the dependencies written down - at least as long you haven't told all package managers like dpkg, apt and aptitude to read and understand your policy as well. Thats why i response here, i just want to help you understand what a package manager will do with your dependencies and that is independent from the content of the package. In the end you will need to write dependencies even a crappy piece of code can understand and at least for me it would be an indicator if even humanoid dependency solvers can't understand them… (Also, while a policy is free to declare that white is the new black it is a good idea to follow established rules and just say black.) Best regards, David Kalnischkies -- 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/aanlktinf89ticqqhqmhaer28lvy-1obtfiug-txzt...@mail.gmail.com