Re: Changes in t1lib.
On Fri, Nov 14, 2003 at 09:20:53PM +0100, Andreas Metzler wrote: > As t1lib-dev (1.3.1) and libt1-dev (5.0.0) are not API compatible I'd > consider that a pseudo-package useless or even unwelcome. Good point. -- G. Branden Robinson|The errors of great men are Debian GNU/Linux |venerable because they are more [EMAIL PROTECTED] |fruitful than the truths of little http://people.debian.org/~branden/ |men. -- Friedrich Nietzsche signature.asc Description: Digital signature
Re: Changes in t1lib.
Branden Robinson <[EMAIL PROTECTED]> wrote: > On Thu, Nov 13, 2003 at 02:23:53PM -0500, Branden Robinson wrote: >> On Mon, Nov 10, 2003 at 08:29:29PM +0100, Artur R. Czechowski wrote: > [...] >> > 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. > [...] >> 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). > [...] >> That's one way to go about this that should not require any >> pseudopackages. > Sorry, I oversold my proposal with that last statement. > Under my proposal you wouldn't need a pseudopackage for t1lib1, but you > would for: > t1lib-dev (Depends: libt1-dev) > t1lib-doc (Depends: libt1-doc) [...] As t1lib-dev (1.3.1) and libt1-dev (5.0.0) are not API compatible I'd consider that a pseudo-package useless or even unwelcome. (You try to compile sarge sources on sid in 12 months, all your build-dependencies are installed, as you have got the t1lib-dev pseudopackage, however the software won't compile, as it does not support the 5.0.0 API.) cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: Changes in t1lib.
On Thu, Nov 13, 2003 at 02:23:53PM -0500, Branden Robinson wrote: > I suggest the following: [cut] Looks good. Ftpmasters probably would kill me, because t1lib5 is uploaded to experimental, but it looks really better than my schedule. If there will be no objection from ftpmaster I will follow your scenario. And for now I set dummy serious bug for t1lib 1.3.1 for not migrating it to testing. I do not like to mess with dependencies and pseudopackages in sarge. Cheers Artur -- Dekolektywizacja stosunków zarządzanie-praca, którą implikuje deregulacja, oddziaływać bedzie dysfunkcyjnie /Raport Międzynarodowego Biura Pracy z 1995 roku/ signature.asc Description: Digital signature
Re: Changes in t1lib.
On Thu, Nov 13, 2003 at 02:23:53PM -0500, Branden Robinson wrote: > On Mon, Nov 10, 2003 at 08:29:29PM +0100, Artur R. Czechowski wrote: [...] > > 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. [...] > 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). [...] > That's one way to go about this that should not require any > pseudopackages. Sorry, I oversold my proposal with that last statement. Under my proposal you wouldn't need a pseudopackage for t1lib1, but you would for: t1lib-dev (Depends: libt1-dev) t1lib-doc (Depends: libt1-doc) and, if you choose to rename it: t1lib-bin (Depends: libt1-bin) -- G. Branden Robinson| Yesterday upon the stair, Debian GNU/Linux | I met a man who wasn't there. [EMAIL PROTECTED] | He wasn't there again today, http://people.debian.org/~branden/ | I think he's from the CIA. signature.asc Description: Digital signature
Re: Changes in t1lib.
Branden Robinson <[EMAIL PROTECTED]> wrote: [t1lib migration] > 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. Another nice thing about this is that even if you only complete #2 before sarge's release it is a huge gain, backports will be a lot easier. cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: Changes in t1lib.
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, [EMAIL PROTECTED] |but that's my general style. http://people.debian.org/~branden/ |-- Ian Jackson signature.asc Description: Digital signature
Re: Changes in t1lib.
On Tue, Nov 11, 2003 at 12:19:03AM +1100, Hamish Moffatt wrote: > Agreed, so why rename it at all? (ie why t1lib -> libt1 if the dummy > package is always going to be required anyway). Not always; just for one Debian release. A dummy package just *smooths* upgrades if you do them right; it doesn't render them impossible. > > What's wrong with libt1-dev? Do you expect to have to support > > development against multiple versions of t1lib? > > Apparently so. Well, he's since followed up and said he won't have to. -- G. Branden Robinson|You can have my PGP passphrase when Debian GNU/Linux |you pry it from my cold, dead [EMAIL PROTECTED] |brain. http://people.debian.org/~branden/ |-- Adam Thornton signature.asc Description: Digital signature
Re: Changes in t1lib.
On Mon, Nov 10, 2003 at 12:04:18AM -0500, Branden Robinson wrote: > Recall that Apt figures out dependency chains for most people. The only > people you're going to offend with the ugliness are people who already > think like Debian developers. And in my experience, one can't cross the > street without offending a Debian developer, so don't worry about it. > ;-) If you say so. I just tried to be friendly :) > You might as well. You're going to end up carrying a dummy package > sooner or later. Indeed. > > The 1.3.1 release is really old. I would like to have it in a good condition > > for sarge, then focus on 5.0.0 and, later, ask to remove 1.3.1. > Well, if you don't want to unleash 5.0.0 into sarge, then that *is* a > good reason for waiting. I have no idea - see below. > > The 5.0.0 package will be consistent with DP 8.1. BTW, how should > > package with development files be named: t1lib5-dev or libt1-5-dev? > What's wrong with libt1-dev? Do you expect to have to support > development against multiple versions of t1lib? No. 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?). Cheers Artur -- jabber:[EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Changes in t1lib.
On Sun, Nov 09, 2003 at 09:20:36PM +0100, Artur R. Czechowski wrote: > On Sun, Nov 09, 2003 at 12:22:14PM +1100, Hamish Moffatt wrote: > > On Tue, Nov 04, 2003 at 11:09:27PM +0100, Artur R. Czechowski wrote: > > > I changed the naming scheme. All binary packages contain version in its > > > name, i.e.: t1lib-dev is now named t1lib1-dev. Of course old packages are > > Hmm. Why? > Incompatibility in API. Software which want to use t1lib 5.x needs changes > in source code. > > > It seems quite common to provide libxyz-dev which always matches the > > latest libxyzN package, even when libxyz1 becomes libxyz2 etc. > So, for now there is t1lib-dev which depends on t1lib1-dev. Any chages after > sarge release (didn't I write it earlier?). > > > It also means that if package X doesn't require any particular version, > You now know this is a false assumption. OK, that makes sense. Thanks. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Changes in t1lib.
On Mon, Nov 10, 2003 at 12:04:18AM -0500, Branden Robinson wrote: > On Sat, Nov 08, 2003 at 10:57:32PM +0100, Artur R. Czechowski wrote: > > These arguments are good, but... > > > > All packages which use this library depend on t1lib1. Of course, I can > > provide dummy t1lib1 package which depends on libt1-1 but I do not like > > this idea. > > I strongly urge you to overcome that dislike. IMO a package should > never disappear across a Debian release unless the functionality has > gone missing. Agreed, so why rename it at all? (ie why t1lib -> libt1 if the dummy package is always going to be required anyway). > What's wrong with libt1-dev? Do you expect to have to support > development against multiple versions of t1lib? Apparently so. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Changes in t1lib.
On Sat, Nov 08, 2003 at 10:57:32PM +0100, Artur R. Czechowski wrote: > These arguments are good, but... > > All packages which use this library depend on t1lib1. Of course, I can > provide dummy t1lib1 package which depends on libt1-1 but I do not like > this idea. I strongly urge you to overcome that dislike. IMO a package should never disappear across a Debian release unless the functionality has gone missing. This is the price we pay for package renames, and if it helps to keep people from renaming packages gratuitously, it's probably a good thing. > Dependency chain: other package -> dummy t1lib1 -> libt1-1 looks > really ugly. It doesn't to me. It looks like par for the course for a rename. Recall that Apt figures out dependency chains for most people. The only people you're going to offend with the ugliness are people who already think like Debian developers. And in my experience, one can't cross the street without offending a Debian developer, so don't worry about it. ;-) > If I removed t1lib1 package it would result in grave bugs in all > dependant packages. Yes, which is why you shouldn't do it. > So, I would not like to do it before sarge release. You might as well. You're going to end up carrying a dummy package sooner or later. > OTOH Build-dependency chain: other package -> dummy t1lib-dev -> t1lib1-dev > also looks bad, but it concerns less machines: only autobuilders and people, > which want to rebuild package for themselves. It looks no better or worse to me. Same ineffeciency brought about by the same need to not hose people doing partial upgrades from woody. > The 1.3.1 release is really old. I would like to have it in a good condition > for sarge, then focus on 5.0.0 and, later, ask to remove 1.3.1. Well, if you don't want to unleash 5.0.0 into sarge, then that *is* a good reason for waiting. > The 5.0.0 package will be consistent with DP 8.1. BTW, how should > package with development files be named: t1lib5-dev or libt1-5-dev? What's wrong with libt1-dev? Do you expect to have to support development against multiple versions of t1lib? -- G. Branden Robinson| Life is what happens to you while Debian GNU/Linux | you're busy making other plans. [EMAIL PROTECTED] | -- John Lennon http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Changes in t1lib.
On Sun, Nov 09, 2003 at 12:22:14PM +1100, Hamish Moffatt wrote: > On Tue, Nov 04, 2003 at 11:09:27PM +0100, Artur R. Czechowski wrote: > > I changed the naming scheme. All binary packages contain version in its > > name, i.e.: t1lib-dev is now named t1lib1-dev. Of course old packages are > Hmm. Why? Incompatibility in API. Software which want to use t1lib 5.x needs changes in source code. > It seems quite common to provide libxyz-dev which always matches the > latest libxyzN package, even when libxyz1 becomes libxyz2 etc. So, for now there is t1lib-dev which depends on t1lib1-dev. Any chages after sarge release (didn't I write it earlier?). > It also means that if package X doesn't require any particular version, You now know this is a false assumption. Cheers Artur -- Tata: Jak się nazywasz? Synek: Igor spacja Sapijaszko.
Re: Changes in t1lib.
On Wed, Nov 05, 2003 at 09:48:29PM +0100, Artur R. Czechowski wrote: > On Wed, Nov 05, 2003 at 02:35:55PM -0500, Aaron M. Ucko wrote: > > If you're renaming them anyway, why not follow Policy 8.1 and > > s/t1lib/libt1-/ (yielding libt1-1, etc.)? > Yes, I thought about it. But there is no strict rule in Policy, just > recommendation. There are many other packages which do not conform to 8.1, > like: e2fslibs, svgalib, zlib, imlib, aalib, beecrypt, slang, cracklib... > Should I go on? For the record, I intend to change binary package names for svgalib, after sarge or once I package 1.9.x for experimental regards, guillem
Re: Changes in t1lib.
On Tue, Nov 04, 2003 at 11:09:27PM +0100, Artur R. Czechowski wrote: > I would like to inform you, that some important changes happened to > t1lib 1.3.1-4[1] package. > > I changed the naming scheme. All binary packages contain version in its > name, i.e.: t1lib-dev is now named t1lib1-dev. Of course old packages are Hmm. Why? It seems quite common to provide libxyz-dev which always matches the latest libxyzN package, even when libxyz1 becomes libxyz2 etc. It also means that if package X doesn't require any particular version, it can build-depend on t1lib-dev and always get the latest version. ie IMHO changing the build-deps of packages that use t1lib would be a bad idea. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Changes in t1lib.
On Sat, Nov 08, 2003 at 03:03:09PM -0500, Branden Robinson wrote: > > OTOH, if you provide me good arguments why I should change name of t1lib, > > and good explanation why a new package, let's say rsplib, does not conform > > to this rule, I will not insist anymore. > 1) Consistency is good, and makes it easier for users to figure out how >the system works. > 2) That other developers are ignorant or disrespectful of good packaging >practices doesn't mean you should be. These arguments are good, but... All packages which use this library depend on t1lib1. Of course, I can provide dummy t1lib1 package which depends on libt1-1 but I do not like this idea. Dependency chain: other package -> dummy t1lib1 -> libt1-1 looks really ugly. If I removed t1lib1 package it would result in grave bugs in all dependant packages. So, I would not like to do it before sarge release. OTOH Build-dependency chain: other package -> dummy t1lib-dev -> t1lib1-dev also looks bad, but it concerns less machines: only autobuilders and people, which want to rebuild package for themselves. The 1.3.1 release is really old. I would like to have it in a good condition for sarge, then focus on 5.0.0 and, later, ask to remove 1.3.1. The 5.0.0 package will be consistent with DP 8.1. BTW, how should package with development files be named: t1lib5-dev or libt1-5-dev? I hope, this is satisfactory. Regards Artur -- opadły mgły i miasto ze snu się budzi, góra czmycha już noc ktoś tam cicho czeka by ktoś powrócił, do gwiazd jest bliżej niż krok pies się włóczy popod murami bezdomny, niesie się tęsknota czyjaś na świata cztery strony signature.asc Description: Digital signature
Re: Changes in t1lib.
On Wed, Nov 05, 2003 at 09:48:29PM +0100, Artur R. Czechowski wrote: > On Wed, Nov 05, 2003 at 02:35:55PM -0500, Aaron M. Ucko wrote: > > If you're renaming them anyway, why not follow Policy 8.1 and > > s/t1lib/libt1-/ (yielding libt1-1, etc.)? > Yes, I thought about it. But there is no strict rule in Policy, just > recommendation. There are many other packages which do not conform to 8.1, > like: e2fslibs, svgalib, zlib, imlib, aalib, beecrypt, slang, cracklib... > Should I go on? Most of those are pretty old, too. > And last but not least: upstream name is t1lib. I do not like to change it > until it is really needed. No one's asking you to change the name of the source package. > OTOH, if you provide me good arguments why I should change name of t1lib, > and good explanation why a new package, let's say rsplib, does not conform > to this rule, I will not insist anymore. 1) Consistency is good, and makes it easier for users to figure out how the system works. 2) That other developers are ignorant or disrespectful of good packaging practices doesn't mean you should be. (And, just so you know, once a certain branch is merged in my XFree86 SVN repository, you won't be able to use "xlibs" as an example to support your case, either. :) ) -- G. Branden Robinson|Lowery's Law: Debian GNU/Linux |If it jams -- force it. If it [EMAIL PROTECTED] |breaks, it needed replacing anyway. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Changes in t1lib.
"Artur R. Czechowski" <[EMAIL PROTECTED]> writes: > And last but not least: upstream name is t1lib. I do not like to change it > until it is really needed. Fair enough; that's probably the best argument. (I similarly resisted renaming alsa-xmms to xmms-alsa because I felt it would be better to keep the upstream name.) At any rate, only the ftpmasters can raise binding objections; since they evidently didn't, I will let it drop and wish you (and the packages) well. -- Aaron M. Ucko (Ucho, historically, AFAICT.)
Re: Changes in t1lib.
On Wed, Nov 05, 2003 at 02:35:55PM -0500, Aaron M. Ucko wrote: > If you're renaming them anyway, why not follow Policy 8.1 and > s/t1lib/libt1-/ (yielding libt1-1, etc.)? Yes, I thought about it. But there is no strict rule in Policy, just recommendation. There are many other packages which do not conform to 8.1, like: e2fslibs, svgalib, zlib, imlib, aalib, beecrypt, slang, cracklib... Should I go on? And last but not least: upstream name is t1lib. I do not like to change it until it is really needed. OTOH, if you provide me good arguments why I should change name of t1lib, and good explanation why a new package, let's say rsplib, does not conform to this rule, I will not insist anymore. Regards Artur -- Z biegiem czasu historia nabiera procentów /Gosia/
Re: Changes in t1lib.
"Artur R. Czechowski" <[EMAIL PROTECTED]> writes: > I changed the naming scheme. All binary packages contain version in its > name, i.e.: t1lib-dev is now named t1lib1-dev. Of course old packages are If you're renaming them anyway, why not follow Policy 8.1 and s/t1lib/libt1-/ (yielding libt1-1, etc.)? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
