-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florent Rougon wrote: > Székelyi Szabolcs <[EMAIL PROTECTED]> wrote: > >> That's right. But why is Replaces needed in the case of an MTA? If a >> package Providing mail-transport-agent is installed, and the user is >> about to explicitly install another package which also Provides and >> Conflicts with mail-transport-agent, then the currently installed >> package will be removed anyway before the new one is installed. I do not >> see the need for Replaces. > > I didn't say it's needed. I even posted an experiment showing that with > the tools from unstable, it makes no difference in: > > apt-get -s install <virtual package> > >> But that's not right. With this, what you've tested is installing the >> virtual package installs the real package instead. That's the way it >> should be. > > It shows that, even when not using Replaces, things do work in this > situation.
You are absolutely right, but that's not what the thread was about. >> But the question is: is Replaces needed to get the previous version >> removed upon installation of the new package? > > What previous version are you talking about? Which "new package"? Installing libfoo1-dev when libfoo0-dev is already installed. The original thread was about the need for "Replaces: libfoo-dev" among the control fields of libfoo0-dev and libfoo1-dev. In this case the "new package" is libfoo1-dev. I think you misunderstood the topic of the thread. We are talking about two different things. Sorry if this is because of my poor composition. >> What if the user forces the installation of the new package by >> overriding the conflict (dpkg --force-conflicts)? Then Replaces can be >> used to take over the files contained in both packages, so dpkg won't >> complain about overwriting files which are contained in another package, >> resulting in a somewhat more consistent installation. > > So, it's right because dpkg doesn't complain when the user it shooting > itself in the foot? If the user uses --force-conflicts, he is on its > own. Agreed. I would add that if we can, we should minimize the impact of a "power" user. That's what I'm trying to do. It's not about dpkg not complaining, it's about dpkg not failing because of "trying to overwrite foo.h which is also in package libfoo0-dev" (or something similar). >> I disagree. Provides is used for that. It has nothing to do with Replaces. > > Fine. I tried to explain how the use of Replaces in the MTA example > could be justified with the information given in Policy. If that is not > enough for you, go argue with the Policy maintainers. I won't. I understand the role of Replaces now. If a package contains files those are contained in another package also, then Replaces must be used. That's the simple rule. And if foo.h is contained in libfoo0-dev and libfoo1-dev, then they should replace each other. An easy and extensible way of doing this is make them Provide the libfoo-dev virtual package and make them Conflict with libfoo-dev also, meaning "all other versions". Thus only one version will be installed. Thanks for your comments anyway. - -- Szabolcs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFLrVUGJRwVVqzMkMRAqBjAKCIC3qH5Azl7A/fV9Il8sQ0DCS6/gCfSmH5 YRr2TUtNWNbG7mNVH76xzZg= =bwZw -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]