Re: How to prevent a library transition
Le jeudi 29 septembre 2005 à 19:18 +0200, Frank Küster a écrit : Josselin Mouette [EMAIL PROTECTED] wrote: Please don't do that. A library transition breaks packages in unstable for a while, but if we have both versions, we're going to have to deal with them for several *years*. That's what happened for libpng, and believe me, it's a nightmare. Why do you think that we would have to deal with both versions for years? I expect no problems in compiling and using packages with the new version, even if their upstream is dead for a while. Then you'll notice that many Debian developers don't rebuild their packages against new library versions, even when told to, until the package becomes uninstallable. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: How to prevent a library transition
Josselin Mouette [EMAIL PROTECTED] wrote: Le jeudi 29 septembre 2005 à 19:18 +0200, Frank Küster a écrit : Josselin Mouette [EMAIL PROTECTED] wrote: Please don't do that. A library transition breaks packages in unstable for a while, but if we have both versions, we're going to have to deal with them for several *years*. That's what happened for libpng, and believe me, it's a nightmare. Why do you think that we would have to deal with both versions for years? I expect no problems in compiling and using packages with the new version, even if their upstream is dead for a while. Then you'll notice that many Debian developers don't rebuild their packages against new library versions, even when told to, until the package becomes uninstallable. That's why I asked about the RC'iness of those bugs: I expect that after a short while, most packages have been recompiled, and it has turned out that there are no problems. Then I submit patches to the remaining packages' bugs, wait for some time, raise severity, wait again, NMU, and can remove the old library. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: How to prevent a library transition
Josselin Mouette [EMAIL PROTECTED] wrote: Please don't do that. A library transition breaks packages in unstable for a while, but if we have both versions, we're going to have to deal with them for several *years*. That's what happened for libpng, and believe me, it's a nightmare. Why do you think that we would have to deal with both versions for years? I expect no problems in compiling and using packages with the new version, even if their upstream is dead for a while. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: How to prevent a library transition
Le mercredi 28 septembre 2005 à 14:53 +0200, Frank Küster a écrit : Wouldn't it be possible to do the following: teTeX-3.0 is uploaded to unstable, including the libkpathsea4 and libkpathsea4-dev packages (it uses the library itself), but at the same time libkpathsea3 and libkpathsea-dev are still available as oldlibs, AND libkpathsea4-dev does *not* provide libkpathsea-dev. Please don't do that. A library transition breaks packages in unstable for a while, but if we have both versions, we're going to have to deal with them for several *years*. That's what happened for libpng, and believe me, it's a nightmare. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: How to prevent a library transition
* Frank Küster ([EMAIL PROTECTED]) [050928 14:54]: Wouldn't it be possible to do the following: teTeX-3.0 is uploaded to unstable, including the libkpathsea4 and libkpathsea4-dev packages (it uses the library itself), but at the same time libkpathsea3 and libkpathsea-dev are still available as oldlibs, AND libkpathsea4-dev does *not* provide libkpathsea-dev. That would work for the library issue, and would only makes some packages FTBFS because tetex changed (but I can think we can live with that). Even better, if you do it right, you can change the libkpathsea-dev to libkpathsea4-dev if TeTeX-3.0 has reached testing, and then the depending programs will slowly flow in (and that library transition wouldn't be as blocking as a normal one). Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to prevent a library transition
On Wed, Sep 28, 2005 at 02:53:59PM +0200, Frank Küster wrote: Wouldn't it be possible to do the following: teTeX-3.0 is uploaded to unstable, including the libkpathsea4 and libkpathsea4-dev packages (it uses the library itself), but at the same time libkpathsea3 and libkpathsea-dev are still available as oldlibs, AND libkpathsea4-dev does *not* provide libkpathsea-dev. You may want to warn the maintainers of your reverse dependencies that they should not upload packages build-depending on libkpathsea4-dev, then. I imagine not everyone reads -devel, and otherwise you'll have a library transition on your hands anyway. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to prevent a library transition
Andreas Barth [EMAIL PROTECTED] wrote: That would work for the library issue, and would only makes some packages FTBFS because tetex changed (but I can think we can live with that). Even better, if you do it right, you can change the libkpathsea-dev to libkpathsea4-dev if TeTeX-3.0 has reached testing, I don't understand - do you mean that I change the name from libkpathsea4-dev to libkpathsea-dev, or that not *me*, but the depending packages' maintainers will change their build-dep from libkpathsea-dev to libkpathsea4-dev? and then the depending programs will slowly flow in (and that library transition wouldn't be as blocking as a normal one). If my second interpretation is right, we depend on maintainers' action for that. In order to make all dependencies on the old version disappear, would a still depends on libkpathsea3 bug be RC? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: How to prevent a library transition
On Wed, 28 Sep 2005, Frank Küster wrote: If my second interpretation is right, we depend on maintainers' action for that. In order to make all dependencies on the old version disappear, would a still depends on libkpathsea3 bug be RC? Yes, fixable with a quick-and-dirty NMU that only does a rebuild against the new one... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: How to prevent a library transition
Frank Kuester wrote: As far as I can see, in this case all other packages would continue using libkpathsea-dev (corresponding to libkpathsea3) for building, and continue to depend on libkpathsea3, which in turn would continue to be available. Only the tetex-bin deb itself would depend on libkpathsea4. Thanks to the name change from libkpathsea-dev (soname version 3) to libkpathsea4-dev, there would be no library transition at all. At some later date, we could trigger the transition, when library transitions are allowed again. So the plan is to make sure that there are no other shared libraries linked to libkpathsea4 at all; only the executables from tetex-bin? That should work, as long as you make sure that nobody else at all links against libkpathsea4. You'll want to mail every maintainer of a package depending on libkpathsea-dev to tell them *not* to update their packages to libkpathsea4 until you give the go-ahead. And then you'll have to mail them all again when you do give the go-ahead! I notice that the symbols in libkpathsea3 are *not* versioned. I'm guessing that the symbols in libkpathsea4 aren't either (if they are, ignore the following). Accordingly, when the transition happens, you'll have to make sure nothing is linked (even indirectly) to both versions. This actually looks like it won't be a problem; I don't think there are any programs which link kpathsea through two different dependency chains (in fact, I only found one library which links to kpathsea: vflib3). -- Nathanael Nerode [EMAIL PROTECTED] Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
