On Mon, Nov 10, 2003 at 08:29:29PM +0100, Artur R. Czechowski wrote: > Let me make myself clear. > > There is t1lib 1.3.1 package in Debian. This is old and unsupported. My goal > is to remove it from Debian. > > There is t1lib 5.0.0. I would like to have it as an only t1lib in distribution. > As I wrote it, it has some changes in API. Just replacing old version with > current one result with FTBFS in some packages (well, probably in all > dependant packages), what is not intended behavior. So we need a way to > both version available in archive. Policy requests, that packages should > contain a soname in this case. That's why I did this fuss about changing > packages name. If there is any error in my thinking, please point it out to > me. > > OTOH, other scenario is possible: > 1. I left package with 1.3.1 version with names: t1lib1, t1lib-dev, > t1lib-doc, t1lib1-bin. Version 5.0.0 is uploaded with names: libt1-5, > libt1-dev, libt1-doc, t1lib-bin. > 2. Dependant packages are modified and recompiled to use v5.0.0 > 3. 1.3.1 is removed, we left with libt1-5, libt1-dev, libt1-doc and > t1lib-bin, for users convenience empty t1lib-dev and t1lib-doc with > dependencies only will be added. > > But it is not consist with Policy, section 8.1. If we agree, that this > migration should be done before sarge release then I go on. If not - the > first way will be realized. Most of all I would like to know RM's opinion > (Anthony, are you there?). I am not sure there is time to completely achieve step #2, which would obviate the need for step #3 (I guess that's why you proposed this "other scenario" :) ). Since t1lib *is* a library, the necessity for explicit migration with pseudopackages is greatly reduced, and possibly eliminated for most practical purposes. I suggest the following: 1. Rename existing t1lib (1.3.1) source package to t1lib-old or something like that. Alter it to provide *only* the t1lib1 and t1lib-dev binary packages. Update t1lib-dev's package description to indicate that this version of the library is strongly deprecated and that developers should port their software to t1lib 5.0.0 instead. Direct them to the libt1-dev package, and a URL to a migration guide if one is available. You might also want to use a NEWS.Debian entry for this purpose. I would also add a note to t1lib1's package description indicating that the package is only depended upon by packages which haven't been updated to use the newer version of the library yet. 2. Package t1lib 5.0.0 as source package t1lib, providing libt1-5, libt1-dev, libt1-doc, and libt1-bin (or t1lib-bin -- Policy doesn't suggest that you name this last item one way or the other). 3. Lean on the maintainers of t1lib-dependent packages to port their stuff to t1lib 5.0.0. Given that it's release season, you'll probably meet with even more resistance than usual. It might be more fruitful to work with package's upstreams. You'll also need to identify any package relationships against t1lib-dev and t1lib-doc (and t1lib-bin, if you rename it to libt1-bin as I suggest), and file bugs against those packages requesting updates. 4. After sarge is released (or before, if by some miracle step 3 is completed before it is too deeply frozen), file a bug against ftp.debian.org requesting the removal of the t1lib-old source package (or whatever you called it). That's one way to go about this that should not require any pseudopackages. Needless to say, steps 1 and 2 should happen in rapid succession, or simultaneously. -- G. Branden Robinson | I'm sorry if the following sounds Debian GNU/Linux | combative and excessively personal, branden@debian.org | but that's my general style. http://people.debian.org/~branden/ | -- Ian Jackson
Attachment:
signature.asc
Description: Digital signature