Hi Phil, Am 09.03.2011 um 22:55 schrieb Philip Brown: > On Wed, Mar 9, 2011 at 12:44 PM, Dagobert Michelsen <[email protected]> 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 _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
