Re: RFC: expat transition or update - before or after lenny?
Am Montag, den 26.05.2008, 22:15 +0200 schrieb Adeodato Simó:
> * Daniel Leidert [Mon, 26 May 2008 17:02:38 +0200]:
>
> > Hello,
>
> Hello Daniel, all -- here are my comments on the matter.
>
> First things first, let's uncouple the two issues at hand: uploading a
> new expat version, and dropping the .0 symlink. I'm not very sure when
> Ardo says in #429175:
>
> | Upgrading expat is a rather tricky thing as due to a major screw up in an
> | NMU many moons ago expat in Debian has two sonames... I haven't found a
> | way around this yet without breaking things like being able to install a
> | binary package that requires this version of expat.
>
> ... what he means. This new upstream release of expat does not bump
> SONAME, so it's just a regular update (hell, it does not even introduce
> *new* symbols).
>
> So, uploading a new version with the current packaging is not a problem
> at all, at least as far as I can see.
>
> Now, for the "dropping the .0 symlink" part. Two important things:
> first, *why* do you want to drop it in the first place?
Well, a library package shipping such a symlink IMHO is rather unusual.
Further the whole situation seems to have been created by shipping
libexpat.so.0 by accident and the quick and dirty solution (so it seems
- I wasn't involved) was to add the symlink. Since then most packages
should have been linked correctly and should not rely on libexpat.so.0.
I would love to get rid of this symlink.
> Second, I'm very much against the "drop it and rename the package" way
> that you seem to be proposing, because that'd be a *gratuitous* and
> *ugly* library transition that may not be needed at all.
>
> Thing is, for almost 7 years the libexpat.so link has pointed to the .1
> name of the library, so the chances that there's anything in our archive
> requiring the .0 name don't look very high.
ACK so far.
> Given that, blindly rebuilding all of expat's r-dependencies, and going
> through a painful migration, just in case there is something referring
> to the old name, sounds like a no-go to me.
I agree. But I cannot see another way to make *sure*, we will not
introduce a broken package. I have no clue, how to check the full
archive for binaries and libraries linking against libexpat.so.0. I
therefor follow(ed) the suggetion by Matthias to make a clean
transition.
> I'd muchly prefer to check *first* if we have within Debian something
> referring to the old name. And, depending on how much stuff there is, go
> for a package rename, or just rebuild that stuff and add conflicts as
> appropriate.
>
> (For stuff people may have unpackaged in their systems... as said above
> chances are slim, and even with a rename of the package we'd break it.)
>
> There is *however* one problematic bit already: wink. It's a package in
> non-free that has a binary without source that links against the .0 name
> (the build failure referred to in the Ubuntu bug report is because of
> this). You can't rebuild that. (You can, though, get in touch with the
> maintainer or author to see if they'd be willing to rebuild.)
Now wink seems to be a problem. But because I would really like to get
rid of this symlink, I can also imagine a different solution. I could
provide a libexpat0-compat package, depending on libexpat1 and just
containing the symlink. When our archive is free of packages, that rely
on this symlink, this package can be safely dropped (depending: lenny+1
or lenny+2). Seems SuSE used some similar solution.
> So, in conclusion, please tell us if there're any compelling reasons to
> really drop the symlink, or to rename the package at all without
> checking first whether there's a big amount of stuff linking against the
> old name (which I doubt there is).
I would of course prefer to update the package without a transition. But
I don't know, how you want to examine, which packages rely on this
symlink [1] to make sure, dropping the symlink will not break another
package.
[1] I can install all r-depends of libexpat1 in a CHROOT and check
everything in *bin and *lib with ldd.
Regards, Daniel
Reply to: