[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: