[csw-maintainers] Obsoleting packages

Philip Brown phil at bolthole.com
Wed Mar 9 22:55:35 CET 2011


On Wed, Mar 9, 2011 at 12:44 PM, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi Phil,
>
> Am 09.03.2011 um 21:31 schrieb Philip Brown:
>
>>> The _devel package is empty of real content but provides a smooth
>>> transition.
>>
>> and do we have a writeup of all this somewheres?
>
> A writeup to have an empty transitional package pulling in a new one?
> We always handled renames this way in the past.

no.. no we havent "always" handled them this way.
We have *occasionally* done that.
Transitioning from old to new smoothly, is a tricky thing.

The "make a stub package to pull in new one", can be nice for "leaf"
packages (dependency speaking), or when a package is depended on by
waaay too many packages to update in a reasonable amount of time.
(although it still has the problem of leaving old obsolete packages
around.. yuck)

However, when a package is "internal" to a dependancy tree, and it has
a limited amount of dependancies, the cleanest way is to NOT make a
stub package, but to rely on our existing [conflicts == auto-replace]
mechanism.

example of using auto-replace:

Start with
softA, depends on libA
softB, depends on libA

libA gets renamed to libShinyA. But presume that at the file level, it
is 100% compatible with "libA". its just a rename.
So, new libShinyA package created. Declared to conflict with libA
softA and softB are repackaged to depend on libShinyA.


User does an update; either a global one, or one specifically for
either softA, or softB.
softA gets upgraded.. which pulls in libShinyA. Which then
auto-removes the older libA

libA has now successfully been transitioned to libShinyA, and there
was no need for a stub package.


More information about the maintainers mailing list