Re: conflicts/replaces/provides vs. breaks/replaces/provides under policy 3.9.1
Hi,
On Mon, Jul 26, 2010 at 05:48:16PM +0200, Bernhard R. Link wrote:
> * Osamu Aoki <osamu@debian.org> [100726 17:27]:
> > =============================================================================
> > 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
>
> Here the provide has advantages and disadvantages. I'd not suggest to
> use it unconditionally here (and even recommend against it in the
> usual cases).
This is good point. Unless some package depends on old package which
is now a transitional package, it is uselss.
> Also note that moving package foo to "oldlibs" makes it easier for
> people to remove such packages.
For my case, this is not applicable but very informative point.
> > =============================================================================
> > 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.
>
> > | Provides: foo
>
> I'd recommend against using recommend here unless in very special cases.
> An additional provides means more work for each dependency resolver.
> And after stable released with no real package with that name, there
> should no longer be any need for it.
I see.
> > Do we do ...
> > | Package: bar
> > | Version: 1.0
> > | Conflicts: foo ( << 1.0 )
> > | Replaces: foo ( << 1.0 )
>
> This only makes sense if you want to make life easier for backporters
> to oldstable.
>
> > Or
> >
> > | Package: bar
> > | Version: 1.0
> > | Conflicts: foo
> > | Replaces: foo
>
> That means foo is to be removed. This means hard decisions for the
> resolver (hopefully it will decide to keep bar and remove foo, and
> not remove both).
OK.
> > Question: Is there sure way to purge the old transitional package foo?
>
> Why do you want to make sure to remove it? It does not cause harm, is
> easy to find and remove. And it might be the only thing keeping bar
> from being removed as a no longer needed dependency.
Good point.
I was thinking xpdf. It was going through package split.
xpdf -> xpdf-common, xpdf-reader, xpdf-utils
It carried so many of conflicts/replaces/provides.
Recent package change removed xpdf-utils functionality and that part is
not packaged. I was going to clean these up. With comments by Russ
and Bernhard, I have better understanding.
Thanks.
Osamu
Reply to: