Guillem Jover <guil...@debian.org> writes:
> On Wed, 2009-09-23 at 10:51:50 +0200, Goswin von Brederlow wrote:
>> Magnus Holmgren <holmg...@debian.org> writes:
>> > When a binary package is renamed or split, as well as if several packages
>> > are
>> > merged under a new name, transitional packages are normally created, which
>> > depend on the new packages, which in turn Replaces and Conflicts with, and
>> > possibly Provides, the old packages. I find those dummy packages as silly
>> > to
>> > create as to uninstall after upgrading.
>>
>> Dpkg has the ability to vanish empty packages. A dummy package should
>> be completly empty and not even contain a /usr/share/doc/. That way on
>> installation the package pulls in its depends and then vanishes. So no
>> more need to uninstall after upgrading. This only works if the
>> superseeding packages Provide the old one though. Otherwise depends on
>> the old package would become unsatisfied.
>
> That's not correct. dpkg only disappears packages that have been
> completely replaced while installing other packages. There's two cases
> for this:
>
> 1. The package to disappear has files that get completely replaced by
> the new one. Needs the Replaces field.
> 2. The disappearing package contains empty directories, and all of
> them are shipped as well by the new package. Does not need
> Replaces field, because directory takeover is an implicit
> Replaces, so this is actually a subcase of 1.
>
> dpkg will never disappear a packages just because it's empty w/o the
> previous conditions. And just to clarify, in no case the Provides field
> plays any role in the disappearing process.
>
> regards,
> guillem
Ok, so one would need to have at least an empty directory (say /usr)
in the package for it to disapear? Why the distinction?
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
