Re: conflicts/replaces/provides vs. breaks/replaces/provides under policy 3.9.1
Osamu Aoki <osamu@debian.org> writes:
> Under this new situation, I would like to confirm what is the best
> practice for each case scenario. Please comment on my thought as below:
> =============================================================================
> Case 1: only one package rule
> install only one package out of packages providing a common virtual package.
> | Package: one-of-package-providing-virtual-package
> | Conflicts: virtual-package
> | Provides: virtual-package
> | Replaces: virtual-package
> Question: Please confirm this is still correct.
This is still correct if the virtual package has requirements that cannot
be satisfied by more than one package at the same time (such as all
providers of that virtual package needing to install a file with the same
path, as is the case for mail-transport-agent).
Of course, the ideal is for providers of a virtual package to not conflict
with each other at all and be co-installable, but that isn't always
possible.
> =============================================================================
> Case 2: package transition rule
> All the contents of the package foo is incorporated by bar in new 1.0
> version and foo 1.0 became a transitional package with no real contents
> which can be removed safely. Please note pre-1.0 version of foo was not
> a transitional package.
> | Package: foo
> | Version: 1.0
> | Description: ...
> | This is a transitional package for foo, and can be safely removed
> | after the installation is complete.
> | Package: bar
> | Version: 1.0
> | Breaks: foo ( << 1.0 )
> | Replaces: foo ( << 1.0 )
> | Provides: foo
> Question: Is this right?
Yes.
> Do we need ( << 1.0 ) for replaces?
You don't strictly need it, but I think it's cleaner, since it catches
mistakes (such as not properly removing the transitioned files from foo).
> =============================================================================
> Case 2': package transition rule
> After stable release with case 2, you wish to remove the transitional
> package foo upon upgrade to unstable/testing/next-stable. I guess we do
> not package "Package: foo" at this moment when uploading.
> Question: Is there sure way to purge the old transitional package foo?
I'm dubious that even attempting to do this is a good idea. I wouldn't
bother.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: