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. Should a package manager really follow the Replaces? This would mean we could end up removing A because A-doc replaces it? 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? > 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… 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… 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/aanlktimyqurbfoka7n_dye0tfiytnmjrkpue9fxi1...@mail.gmail.com
