Re: conflicts/replaces/provides vs. breaks/replaces/provides under policy 3.9.1
Osamu Aoki <osamu@debian.org> writes:
> Hi folks,
>
> Breaks field was added to policy in 3.8 and current stable dpkg supports
> it as I understand. So we are ready to use it, as I understand.
>
> 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 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?
Actualy I think the Breaks is wrong and Conflicts must be used. Consider
the following sequenze of commands:
dpkg -i foo_0.1.deb
dpkg -i --auto-deconfigure bar_1.0.deb
dpkg --purge bar
dpkg --configure -a
After this foo 0.1 is installed and configured. It is also totaly broken
because all its files are gone (except /usr/share/doc/foo).
There was a discussion about this on debian-policy some month back but
I lost track of the it and the conclusion.
Also I consider the Provides optional. If it is some well known package
people are likely to install manually then a Provides is nice,
esspecially when foo is later removed, because it the new package can be
found under the old name. If the foo is just something that gets
installed through depends then the provides is not that usefull.
> Do we need ( << 1.0 ) for replaces?
It is cleaner. Someone (not Debian) might package a new foo 2.0 package
because they don't rename the package and then you get a proper error if
foo 2.0 and bar are mixed.
It also makes the rule the same as 2' and 3 so you only have to remember
one rule.
> =============================================================================
> 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?
>
> Do we do ...
> | Package: bar
> | Version: 1.0
> | Conflicts: foo ( << 1.0 )
> | Replaces: foo ( << 1.0 )
> | Provides: foo
>
> Or
>
> | Package: bar
> | Version: 1.0
> | Conflicts: foo
> | Replaces: foo
> | Provides: foo
Just leave it as it is. If it ain't broken, don't fix it.
| Package: bar
| Version: 1.0
| Conflicts: foo ( << 1.0 )
| Provides: foo
=============================================================================
Case 3:
One or more files are moved from foo to bar but not everything.
| Package: foo
| Version: 1.0
|
| Package: bar
| Version: 1.0
| Conflicts: foo ( << 1.0 )
MfG
Goswin
Reply to: