conflicts/replaces/provides vs. breaks/replaces/provides under policy 3.9.1
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 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.
=============================================================================
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?
Do we need ( << 1.0 ) for replaces?
=============================================================================
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
Osamu
Reply to: