[csw-maintainers] Obsoleting packages

[Dagobert Michelsen]

Hi Phil,

Am 09.03.2011 um 22:55 schrieb Philip Brown:
> 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.

From the task to clean package names in release "dublin" we are targetting
I estimate about 500 renames. Handling this on an individual basis is IMHO
prone to errors while always using intermediate packages is a simple, clean
and easy way to achieve consistent updating. The "I" workaround was necessary
to avoid leaving outdated packages around. Now with the "i obsolete" marker
the packaging tool has a clean indication when a package can safely be
removed and the I-workaround is no longer needed. 

Following the "I"-approach consistently would probably require rebuilding
the whole set and pushing 500 packages at once which would be much harder
to do right and to verify.


Best regards

  -- Dago