Re: conflicts/replaces/provides vs. breaks/replaces/provides under policy 3.9.1

[Goswin von Brederlow <goswin-v-b@web.de>]

"Bernhard R. Link" <brlink@debian.org> writes:

> 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

The "Conflicts: foo" would remove it. And the n bar gets removed because
it is "automatic". Also the users most loves baz package, which still
depends on foo because it hasn't been updated, gets removed too.

I would just leave it as it is with the versioned Conflicts.

MfG
        Goswin