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. Suppose package A (=1) contains /usr/share/doc/A/examples/config; the successor is A-doc (=2) which contains /usr/share/doc/A-doc/examples/config. There is no file conflict and no need for Conflicts: or Replaces:. Now, just to make the example more twisted, suppose the new A-doc contains a symlink: /usr/share/doc/A-doc -> A and, of course, Depends: on the exact version of A, i.e. Package: A-doc Depends: A (=2) (per Debian Policy in such cases). Then there is still no conflict and no need for Conflicts: or Replaces: because A-doc can never be installed at the same time as the old A. > Should a package manager really follow the Replaces? I think so, yes. If I take the trouble to specify Replaces, I mean it. If I do *not* want the package manager to follow the Replaces, then I specify Conflicts but *not* Replaces. Why else do we have two different relationships? > This would mean we could end up removing A because A-doc replaces it? No, per my explanation above; instead, the package manager would install the new A and the new A-doc. > Or get full blown documentation - now that you have used the > application for years without looking at the (non existing) > documentation so far… You can construct for Conflicts a similar (and > better) situation, 'extra' packages for example can Conflicts/Replaces > with each other without any problems… > > Both together doesn't indicate much as well: > Your installed mail-transport-agent conflicts+replaces all other MTAs. > Is installing exim4 instead of postfix really an upgrade path? I do not think mail-transport-agents should necessarily Replace each other. They should only Conflict with each other. >> Let me emphasize again that, for Ada, a new version of a -dev package >> (i.e. libX2-dev) is *not* a complete replacement for libX1-dev, >> therefore we must use neither a dummy transitional package nor a >> Provides relationship. > > The question is why you want that people which have libX1-dev installed > need to upgrade to libX2-dev AND remove libX1-dev by describing that > only with dependencies in libX2-dev. It is simply not possible and > doesn't make much sense: > If libX1-dev can't be used anymore the package breaking it should > "Breaks" it. If it is not broken why removing it? > It will be autoremoved if it is not needed anymore… The problem with -dev packages is that, usually, nothing depends on them (apart for other -dev packages); they are only ever installed when a user explicitly requests so, so aptitude will *not* autoremove them. 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. > libX2-dev will be installed then something depends on it - or if the user > needs it and requests it manually. > I also don't see why libX1-dev and libX2-dev have Conflicts and/or > Replaces on each other. Their naming _highly_ suggests > that they can be co-installed and used. If they can't be co-installed > and used why is the package not called libX-dev instead… 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. -- Ludovic Brenta. -- 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/87wrul5d24....@ludovic-brenta.org
