[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



Not answering the Conflics/Breaks issue, but some remark about Provides.

* 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).

Also note that moving package foo to "oldlibs" makes it easier for
people to remove such packages.

> =============================================================================
> 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.

> 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).

> 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.

	Bernhard R. Link
-- 
"Never contain programs so few bugs, as when no debugging tools are available!"
	Niklaus Wirth


Reply to: