|
Home > Archive > Debian Developers > June 2004 > Re: libpkg-guide updated (versioned symbols), please proofread
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: libpkg-guide updated (versioned symbols), please proofread
|
|
| Steve Langasek 2004-06-02, 7:51 am |
| On Tue, Jun 01, 2004 at 04:52:35PM -0400, Stephen Frost wrote:
> -dev packages should *NOT* depend on other -dev packages unless their
> public .h files #include files from those other -dev packages (which
> generally shouldn't be the case). That whole crap was due to the lack
> of understanding of the problem and blindness to the proper solution
> (versioned symbols). The result is that it just makes things FTBFS and
> doesn't actually fix the problem anyway. Not exactly useful.
The reason for dependencies between -dev packages was libtool's failure
to accomodate glibc's transitive dependency support, which is a separate
issue than versioned symbols (though both contribute to the overall
problem).
> As I recall, libdb doesn't actually use versioned symbols anymore but
> instead uses a hack because versioned symbols aren't supported on all
> architectures.
Debian's db packages still use versioned symbols.
--
Steve Langasek
postmodern programmer
| |
| Junichi Uekawa 2004-06-02, 7:51 am |
|
>
> Hopefully 'shared' libraries.
Yes, my mistake. Thanks.
>
> The 'migration strategy' is misleading.
Thanks for your feedback.
I'm going to change the text so that the migration strategy is
less misleading.
regards,
junichi
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Junichi Uekawa 2004-06-11, 6:30 pm |
|
Hi,
Thanks for your comments.
> [1 <text/plain; us-ascii (quoted-printable)>]
> * Junichi Uekawa (dancer@netfort.gr.jp) wrote:
>
> Alright, some additional corrections (didn't I do this before?):
>
> Packages which contain multiple shared libraries are fine provided they
> don't unduly increase the amount of crap that needs to be updated (such
> as existed with xlibs) and handle compatibility issues (as libc6 does).
I'll write a footnote on that topic.
However, as an introductory guide to shared library packaging,
that is rather much of a gory detail.
> -dev packages should *NOT* depend on other -dev packages unless their
> public .h files #include files from those other -dev packages (which
> generally shouldn't be the case). That whole crap was due to the lack
> of understanding of the problem and blindness to the proper solution
> (versioned symbols). The result is that it just makes things FTBFS and
> doesn't actually fix the problem anyway. Not exactly useful.
This part does not entirely apply to Debian since we keep static libraries
and try to keep them useful. I've added notes on why the Depends is
actually required for the functioning of a -dev package.
o for static linking
o for header files and inclusions
> Build-Depend's should be *accurate* in that they map to the *API* that's
> required. Sometimes this works out as being the same as the SONAME, but
> that's not always the case. Multiple ABI's can be associated with a
> single API. This is actually the case with OpenLDAP which claims, at
> least, to have not broken backwards compatibility with the API since the
> 1.x days, though the ABI has changed a number of times. Of course, if a
> package depends on parts of the API that were added later they should
> version their build-depends appropriately. In general it'd probably
> actually be good to get away from having version numbers in -dev package
> names based on the expectation that upstream will be similar to the
> OpenLDAP case, and in the event that the API is changed in a way which
> is not backwards compatible the library name may be changed in some
> other way.
I'm not quite sure what portion of libpkg-guide this comment
refers to;
> Using -Bsymbolic is just a bad idea in general, and should be avoided.
I've added a note there to use symbol versioning instead.
Nice to see feedbacks 
regards,
junichi
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marcelo E. Magallon 2004-06-12, 11:51 pm |
| On Tue, Jun 01, 2004 at 04:52:35PM -0400, Stephen Frost wrote:
> That whole crap was due to the lack of understanding of the problem
> and blindness to the proper solution (versioned symbols).
Whilst I agree with you as a library author myself, I disagree with you
as a Debian maintainer.
Debian should _not_ introduce gratuitous differences with upstream
authors. While we have fscked up in this point big time and multiple
times (myself being guilty of that charge), that doesn't mean we should
keep doing that. Nowadays it's possible to compile a simple hello
world C program on an unstable system and run it on a current yet
random Linux Distribution. That wasn't the case one or two years ago
because Debian kept "fixing" upstream problems. Nowadays it's even
possible to do the same with C++ programs.
Looking who and how libpkg-guide is used, I think this document should
make it _very_ clear that this kind of changes _must_ be send upstream
and they must _not_ be included in Debian packages in advance.
Marcelo
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2004-06-12, 11:51 pm |
| On Fri, Jun 11, 2004 at 08:06:04PM -0600, Marcelo E. Magallon wrote:
> On Tue, Jun 01, 2004 at 04:52:35PM -0400, Stephen Frost wrote:
[vbcol=seagreen]
> Whilst I agree with you as a library author myself, I disagree with you
> as a Debian maintainer.
> Debian should _not_ introduce gratuitous differences with upstream
> authors. While we have fscked up in this point big time and multiple
> times (myself being guilty of that charge), that doesn't mean we should
> keep doing that. Nowadays it's possible to compile a simple hello
> world C program on an unstable system and run it on a current yet
> random Linux Distribution. That wasn't the case one or two years ago
> because Debian kept "fixing" upstream problems. Nowadays it's even
> possible to do the same with C++ programs.
While it's definitely important to push changes such as symbol
versioning upstream, it should be noted that Debian-specific symbol
versions do not prevent you from taking binaries built elsewhere and
running them on Debian systems. They do prevent you from taking
binaries built on Debian and running them elsewhere; but given that
failing to use versioned symbols frequently causes binaries built on
Debian to not run on *Debian*, I believe this is the lesser of two
evils.
--
Steve Langasek
postmodern programmer
| |
| Mark Brown 2004-06-13, 5:51 pm |
| On Sat, Jun 12, 2004 at 01:19:58PM -0500, Steve Langasek wrote:
> running them on Debian systems. They do prevent you from taking
> binaries built on Debian and running them elsewhere; but given that
> failing to use versioned symbols frequently causes binaries built on
Both cases are important - I know I've personally made a reasonable
amount of use of the ability to run Debian built binaries on other
systems.
There's also the problem that if we do end up fixing bugs by doing this
then developers working on Debian may have a much harder time supporting
users on other systems. Problems will still occur but if we've bodged
around them locally then they'll not be visible on Debian systems.
> Debian to not run on *Debian*, I believe this is the lesser of two
> evils.
It does seem rather rude to do this without upstream, which is also a
consideration.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marcelo E. Magallon 2004-06-13, 5:51 pm |
| On Sat, Jun 12, 2004 at 01:19:58PM -0500, Steve Langasek wrote:
> They do prevent you from taking binaries built on Debian and running
> them elsewhere; but given that failing to use versioned symbols
> frequently causes binaries built on Debian to not run on *Debian*, I
> believe this is the lesser of two evils.
I sympathize with that argument in principle. If I'm given to choose
between dealing with a problem globaly and _at least_ fixing it
locally, in general I'd go for fixing it _at least_ locally. That is,
if I can fix it _at least_ in the Debian case, I'd go for it. But with
respect to this particular topic, this harms Debian significantly: "oh,
Debian, you can't use that to develop software, it won't run
elsewhere". You know how hard that kind of reputation is to shake.
Put it another way: yes, in the short run it's better to fix this at
least for Debian. But in the long run this creates a much bigger
problem.
Marcelo
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Stephen Frost 2004-06-14, 5:54 pm |
| * Marcelo E. Magallon (mmagallo@debian.org) wrote:
> Put it another way: yes, in the short run it's better to fix this at
> least for Debian. But in the long run this creates a much bigger
> problem.
I'm confident everyone wants to push these changes back upstream and
educated library authors on why they should be including these changes.
That *should* take care of the 'long term', and if it doesn't then there
are much bigger problems. For the 'short term' fixing this problem just
for Debian is good since it means we won't have segfaults for lots of
programs every time we update something.
Stephen
| |
| Josselin Mouette 2004-06-15, 5:55 pm |
| Le sam 12/06/2004 à 20:19, Steve Langasek a écrit :
> While it's definitely important to push changes such as symbol
> versioning upstream, it should be noted that Debian-specific symbol
> versions do not prevent you from taking binaries built elsewhere and
> running them on Debian systems. They do prevent you from taking
> binaries built on Debian and running them elsewhere; but given that
> failing to use versioned symbols frequently causes binaries built on
> Debian to not run on *Debian*, I believe this is the lesser of two
> evils.
Actually, this is wrong. Recent versions of ld-linux.so.2 only display a
warning when some symbols require a version that doesn't exist. If you
build a binary on Debian and link it to a library that has
Debian-specific versioned symbols, it will run on a non-Debian system,
provided that this system doesn't tag the same symbols with a different
version.
--
.''`. Josselin Mouette /\./\
: :' : josselin.mouette@ens-lyon.org
`. `' joss@debian.org
`- Debian GNU/Linux -- The power of freedom
| |
| Stephen Frost 2004-06-15, 5:55 pm |
| * Josselin Mouette (joss@debian.org) wrote:
> Actually, this is wrong. Recent versions of ld-linux.so.2 only display a
> warning when some symbols require a version that doesn't exist. If you
> build a binary on Debian and link it to a library that has
> Debian-specific versioned symbols, it will run on a non-Debian system,
> provided that this system doesn't tag the same symbols with a different
> version.
This is certainly good news. Do you know which (if any)
distributions/releases have the newer version of ld-linux.so.2? It'd be
very useful to know where things will break and where they shouldn't.
Stephen
| |
| Josselin Mouette 2004-06-15, 5:55 pm |
| Le mar 15/06/2004 à 15:42, Stephen Frost a écrit :
> * Josselin Mouette (joss@debian.org) wrote:
>
> This is certainly good news. Do you know which (if any)
> distributions/releases have the newer version of ld-linux.so.2? It'd be
> very useful to know where things will break and where they shouldn't.
I made some tests a year ago before uploading libpng packages using
versioned symbols. It worked at least on Mandrake cooker (so you can
expect it to work on 9.1+) and SuSE 8.something.
--
.''`. Josselin Mouette /\./\
: :' : josselin.mouette@ens-lyon.org
`. `' joss@debian.org
`- Debian GNU/Linux -- The power of freedom
|
|
|
|
|