Re: Listing dependencies with specific versions
On Tue, 9 Dec 2008 20:17:02 +0100 Cyril Brulebois <[EMAIL PROTECTED]> wrote: > Neil Williams <[EMAIL PROTECTED]> (09/12/2008): > > *shrug*. Knowing the Debian Policy would help compensate that bias. I think you've missed my point - the change is done anyway, it's just done as part of an upstream process not as a separate task. I considered "adding a symbol" as a single task, you (and others) see it as two and I can now see why that happens. It does not mean that the task itself was not being done or that I was unaware of the requirements. I was merely unaware of the division - I saw the entire thing as one, that is all. I didn't recognise that what was being described as "shlib bump" was something I was already doing. > Not to mention that you aren't advising upstreams here, but Debian > packagers, so I'd even expect good knowledge of the Policy. I was not and am not unaware of Policy - just that something that I took for granted was actually not being done in other packages. > > I use symbols instead now and that is a far better system - easier > > to manage upstream too. > > Still, knowing the basics... Not true. > > [Various stats, etc.] I don't think a genuine mistake is grounds to > > disrespect my contribution. > > As I already stated, what I hate is your repeating you're right > (“Cyril, we've had this discussion before” etc.) when you're being > clueless. Making a simple mistake, I apologise for that. > > Umm, adding symbols properly does not require a SONAME bump - you've > > said so yourself. The confusion is what is meant by "properly" - I > > considered "properly" as including the shlibs (or preferably > > symbols) support, not as a separate task. Dumping new symbols into > > the library without any packaging support is not a good idea, I've > > never doubted that. (Just didn't expect others to be neglecting it). > > So you claim you're doing your job right (note that I'm not > questioning that), by playing with symbols while you didn't know > anything about shlibs (read it as “confusing them with SONAME”) > before some minutes ago? Impressive. I know about shlibs, I just didn't identify that for what I thought was one complete step, some packages had only part of the implementation. Anyway, can we move on now? -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgp97Y6k3tGRe.pgp Description: PGP signature
Re: Listing dependencies with specific versions
Neil Williams <[EMAIL PROTECTED]> (09/12/2008):
> You're talking about the shlib, as explained in my other message, I
> was inadvertently folding the two into one. My mistake.
Finally.
> > You *do* understand the concept of SONAME and shlibs, right?
>
> Yes, but adding symbols "properly" includes the shlib change and I
> wasn't thinking of it as a separate step, just a routine part of
> adding a symbol. Upstream bias.
*shrug*. Knowing the Debian Policy would help compensate that bias. Not
to mention that you aren't advising upstreams here, but Debian
packagers, so I'd even expect good knowledge of the Policy.
> I use symbols instead now and that is a far better system - easier to
> manage upstream too.
Still, knowing the basics...
> The RC bugs in question are not against my own packages, I was merely
> reviewing the existing bugs to try and get Lenny released.
Oh, you were adding random noise (buggy severity change, tag addition)
to #50707{1,2}? Then I do recognize my mistake assuming you were the
maintainer.
> [Various stats, etc.] I don't think a genuine mistake is grounds to
> disrespect my contribution.
As I already stated, what I hate is your repeating you're right (“Cyril,
we've had this discussion before” etc.) when you're being clueless.
> > Again, wrong.
>
> Umm, adding symbols properly does not require a SONAME bump - you've
> said so yourself. The confusion is what is meant by "properly" - I
> considered "properly" as including the shlibs (or preferably symbols)
> support, not as a separate task. Dumping new symbols into the library
> without any packaging support is not a good idea, I've never doubted
> that. (Just didn't expect others to be neglecting it).
So you claim you're doing your job right (note that I'm not questioning
that), by playing with symbols while you didn't know anything about
shlibs (read it as “confusing them with SONAME”) before some minutes
ago? Impressive.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: Listing dependencies with specific versions
On Tue, 9 Dec 2008 18:12:56 + (UTC) Andy Hawkins <[EMAIL PROTECTED]> wrote: > >> Can someone confirm / deny my understanding here? As I say, I'm > >> very new to all this. > > > > Sorry to inflict my mistake upon you. It happens to everyone at some > > point. > > Whoops. It appears the mistake is mine. Picture support was actually > added in flac 1.1.3, not 1.2.0 as I thought. In which case, the bug would only show if the package was in unstable and then installed on Etch as that has 1.1.2. That would be a problem for a package in Debian as it would risk a failure during a migration from Etch to Lenny but your package has no real chance of getting into Lenny. > Mea culpa. (join the club) > My .deb however doesn't depend on a specific version of libflac, is > that because there are no versions prior to this available? It's because of the bug in flac and because you haven't used the workaround. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgp7bRVEtIHj4.pgp Description: PGP signature
Re: Listing dependencies with specific versions
Andy Hawkins <[EMAIL PROTECTED]> (09/12/2008): > My .deb however doesn't depend on a specific version of libflac, is > that because there are no versions prior to this available? It is because currently, libflac doesn't declare its shlibs properly. Once this is fixed, and once your package has been rebuilt against it, your package's dependencies against libflac will gain a (>= $version). Mraw, KiBi. signature.asc Description: Digital signature
Re: Listing dependencies with specific versions
Hi, In article <[EMAIL PROTECTED]>, Neil Williams<[EMAIL PROTECTED]> wrote: >> Can someone confirm / deny my understanding here? As I say, I'm very >> new to all this. > > Sorry to inflict my mistake upon you. It happens to everyone at some > point. Whoops. It appears the mistake is mine. Picture support was actually added in flac 1.1.3, not 1.2.0 as I thought. Mea culpa. My .deb however doesn't depend on a specific version of libflac, is that because there are no versions prior to this available? Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
On Tue, 9 Dec 2008 17:34:15 + (UTC) Andy Hawkins <[EMAIL PROTECTED]> wrote: > Now I'm confused. That's my fault. There is a bug in the shlibs of libflac++ > Is there a bug in the libflac++ stuff or not? The > way I see it: Yes - just in the shlibs which is much easier to fix. > 1. If my software is compiled against libflac1.1.x, it won't include > picture support, so will work with a version of libflac1.1.x *or* > libflac1.2.x Once libflac++ is fixed, dpkg-shlibdeps will pick up the right version and give you the strict dependency that you need. Until it is fixed, you can work around the bug but that won't protect anyone else building against the library. Your package should not be capable of being built against libflac1.1 because it should check for 1.2 in the configure stage. Your package is what requires symbols from 1.2, your package needs to check for that. Once built, if it is installed alongside 1.1 (despite being built against 1.2), then it will fail because it is looking for symbols that only exist in 1.2 - that is the bug in the library. > 2. If my software is compiled against libflac1.2.x, it *will* include > picture support so *won't* work with a version of libflac1.1.x, only > libflac2.2.x Yes. You need to ensure that it is built against 1.2. > 3. When I build my package on testing, it compiles and links against > libflac1.2.x. So, it includes picture support. *However*, the > dependencies for the binary package only say it depends on libflac, > no libflac >= 1.2.x Which is the bug in the library that you can work around. > Can someone confirm / deny my understanding here? As I say, I'm very > new to all this. Sorry to inflict my mistake upon you. It happens to everyone at some point. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpZMcEFozM36.pgp Description: PGP signature
Re: Listing dependencies with specific versions
Hi, In article <[EMAIL PROTECTED]>, Andy Hawkins<[EMAIL PROTECTED]> wrote: > Umm, I'll try. I'm not sure exactly what that bug report should say! Kind of > new to all this Debian packaging stuff (as of this time last week I knew > nothing about it!). Now I'm confused. Is there a bug in the libflac++ stuff or not? The way I see it: 1. If my software is compiled against libflac1.1.x, it won't include picture support, so will work with a version of libflac1.1.x *or* libflac1.2.x 2. If my software is compiled against libflac1.2.x, it *will* include picture support so *won't* work with a version of libflac1.1.x, only libflac2.2.x 3. When I build my package on testing, it compiles and links against libflac1.2.x. So, it includes picture support. *However*, the dependencies for the binary package only say it depends on libflac, no libflac >= 1.2.x Can someone confirm / deny my understanding here? As I say, I'm very new to all this. Cheers Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
On Tue, 9 Dec 2008 17:14:05 +0100 Cyril Brulebois <[EMAIL PROTECTED]> wrote: > > The bug only arises if symbols are removed or function prototypes > > are changed in existing symbols. > > Wrong. You're talking about the shlib, as explained in my other message, I was inadvertently folding the two into one. My mistake. > You *do* understand the concept of SONAME and shlibs, right? Yes, but adding symbols "properly" includes the shlib change and I wasn't thinking of it as a separate step, just a routine part of adding a symbol. Upstream bias. I use symbols instead now and that is a far better system - easier to manage upstream too. > You *do* > understand that those are different things, right? Given some RC bugs > against some of your packages, I start doubting it. Too bad you're > being so vocal on this list, and so self-confident. I've apologised for the confusion, I don't mind owning up to errors and misconceptions. The RC bugs in question are not against my own packages, I was merely reviewing the existing bugs to try and get Lenny released. I have no open RC bugs against any of my own 61 packages (and haven't for several months) and none against my sponsored packages either. Since the freeze started, I've made numerous RC fix NMU's, contributed to fixes for many others. If more DD's had been as active, Lenny could well have been released on time (or certainly by now). I don't think a genuine mistake is grounds to disrespect my contribution. > > > Hopefully more libraries will adopt the new dpkg symbols stuff so > > > that this can be detected and fixed more often. Definitely - a possible release goal for Squeeze that one. After all, mole has the basic files available already. > > The fix is only necessary if the symbol has CHANGED - added symbols > > can be managed perfectly well without a SONAME bump. > > Again, wrong. Umm, adding symbols properly does not require a SONAME bump - you've said so yourself. The confusion is what is meant by "properly" - I considered "properly" as including the shlibs (or preferably symbols) support, not as a separate task. Dumping new symbols into the library without any packaging support is not a good idea, I've never doubted that. (Just didn't expect others to be neglecting it). Adding symbols means modifying the symbols file - or at least adding symbols "properly" means that. Modifying the symbols file (the much improved replacement of shlibs) should be part and parcel of the one task of adding a new symbol to the library and is much easier to manage upstream. Adding symbols support to Debian libraries means that this problem becomes much, much more obvious and far, far easier to fix. I think it would be a valuable goal for Squeeze to get symbols support in all libraries in testing. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpYleyNdFII7.pgp Description: PGP signature
Re: Listing dependencies with specific versions
On Wed, Dec 10, 2008 at 1:38 AM, Matthew Palmer <[EMAIL PROTECTED]> wrote: > Sure, if the package that is building needs those symbols. But what about > other packages that *don't* necessarily need those symbols, but get built > against the newer version of the library anyway? Those symbols can end up > in the built binary, but unless dpkg-shlibdeps happens to know that symbols > have been added, it won't know to version the library dependency and all > hell breaks loose. > > The solution: shlibs files, which list the last package version in which a > new symbol was added to the library, so that the packaging system can make > sure that that newer version is available to packages that need the extra > symbols. These days, shlibs has been obsoleted by the new symbols files stuff (which isn't used in libflac++6 AFAICT), so that for each package will depend on the minimum version of the library that provides all the symbols required by the package. This rocks, helps allow installing stuff from testing on stable, eases upgrades and partial upgrades and helps the release team maintain sanity. I just hope it gets used more in squeeze. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
On Tue, Dec 09, 2008 at 04:06:46PM +, Neil Williams wrote: > On Tue, 9 Dec 2008 22:18:01 +0900 > "Paul Wise" <[EMAIL PROTECTED]> wrote: > > > On Tue, Dec 9, 2008 at 9:40 PM, Andy Hawkins <[EMAIL PROTECTED]> > > wrote: > > > > > New symbols. It specifically has support for embedding images into > > > the FLAC file. This was introduced in 1.2. > > > > Looks like you just found an RC bug in libflac++6 - includes new > > symbols in version 1.2.1-1 according to mole but the shlibs does not > > depend on that version: > > That is not a bug - the package building against it merely has to > require that version. Sure, if the package that is building needs those symbols. But what about other packages that *don't* necessarily need those symbols, but get built against the newer version of the library anyway? Those symbols can end up in the built binary, but unless dpkg-shlibdeps happens to know that symbols have been added, it won't know to version the library dependency and all hell breaks loose. The solution: shlibs files, which list the last package version in which a new symbol was added to the library, so that the packaging system can make sure that that newer version is available to packages that need the extra symbols. > The bug only arises if symbols are removed or function prototypes are > changed in existing symbols. Not quite. If you remove symbols or change the type of a symbol, you need to bump the SONAME because that's the only piece of information that the dynamic linker has to be able to determine if a *newer* library will or won't work with a particular binary. If you add symbols, you don't need to bump the SONAME because the library is still backwards-compatible -- the SONAME effectively defines a "base ABI" that will continue to work into the future, and when that no longer applies, *then* the SONAME is bumped. > If it was, we'd be on libglib.so.7787.0.0 by now. *cough* /usr/lib/libglib-2.0.so.0.1600.6 Not quite, but close... > > Hopefully more libraries will adopt the new dpkg symbols stuff so that > > this can be detected and fixed more often. > > The fix is only necessary if the symbol has CHANGED - added symbols can > be managed perfectly well without a SONAME bump. Yes, you are perfectly correct about this. But we're not referring to a SONAME bump, we're talking about putting correct information in the shlibs file regarding new symbols. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
On Wed, 10 Dec 2008 01:06:16 +0900 "Paul Wise" <[EMAIL PROTECTED]> wrote: > On Wed, Dec 10, 2008 at 1:03 AM, Neil Williams <[EMAIL PROTECTED]> > wrote: > > > Cyril, we've had this discussion before - merely adding symbols does > > NOT require a SONAME bump. > > We are not talking about SONAME bumps, but shlib bumps. OK, I've had a quite chat with Suno on IRC and cleared up the confusion in my own mind - basically, some maintainers are are not doing something that I do by second nature - managing the shlibdeps when a new symbol is added. I add the details to the symbols file and sort out the shlibs without even thinking of the two as separate. What everyone is thinking of as an shlib bump is something I simply do as part of "adding a symbol" the proper way. Hence, my original supposition that "adding a new symbol properly does not require a SONAME bump" - which was correct but not relevant here. I see the division now. "Adding a symbol" in my mind included the "shlib bump" as a direct and inevitable consequence. Ah well. > > I doubt that - merely adding a new symbol is NOT a bug, let alone > > release-critical. > > Right, but not bumping shlibs at the same time is an RC bug AFAIK. OK, I've got that now. Sorry for the noise. Maybe this is just because I'm also upstream for my libraries and this sort of thing comes naturally, without even thinking of it as a separate step. I just didn't consider that people would do something as crazy as only do half a change. I'm not afraid of saying I got this bit wrong but I hope it's clearer now. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpUnpUd0djfp.pgp Description: PGP signature
Re: Listing dependencies with specific versions
Paul Wise <[EMAIL PROTECTED]> (10/12/2008): > > Specify the strict version ahead of shlib:Depends and dpkg-shlibdeps > > does the right thing. > > Thats a hack. Another workaround for broken shlibs is > debian/shlibs.local. A very dirty one. The other being the one recommended by the Policy, but I don't really want mentored people to try and handle this kind of problem this way, especially if mentored by clueless people (I'm not thinking about you, Paul :) you already know that we agree on this topic). Mraw, KiBi. signature.asc Description: Digital signature
Re: Listing dependencies with specific versions
Neil Williams <[EMAIL PROTECTED]> (09/12/2008): > Adding a new function (or several hundred new functions) has > absolutely ZERO impact on the SONAME as long as the new functions do > not overlap existing functions, change existing functions or require > any changes elsewhere in the library that remove or modify existing > symbols. And I said ZERO things about the SONAME, would you please learn to read? And yes, Gtk people are good at not breaking the ABI. But that has ZERO things to do with the current topic. Please (re)focus. > Cyril, we need to sort this out for that RC bug that doesn't exist but > which you raised the severity - adding a new symbol is NOT a bug, as > long as it is done properly (as above). It wasn't in your packaging. Again, shlibs. Again, shlibs!=SONAME. Maybe you've got a broken strcmp() implementation? > It is up to the package using the library to build-depend on the right > version and use a strict dependency on that version or later that > supercedes the plain dependency. > > i.e. exactly what I recommended for this package. > > Specify the strict version ahead of shlib:Depends and dpkg-shlibdeps > does the right thing. What if you read the Policy? Like e.g. 8.6 (more specifically 8.6.3). I thought it was a prerequisite for doing Debian stuff. Mraw, KiBi. signature.asc Description: Digital signature
Re: Listing dependencies with specific versions
On Wed, Dec 10, 2008 at 1:15 AM, Neil Williams <[EMAIL PROTECTED]> wrote: > Cyril, we need to sort this out for that RC bug that doesn't exist but > which you raised the severity - adding a new symbol is NOT a bug, as > long as it is done properly (as above). > > It is up to the package using the library to build-depend on the right > version and use a strict dependency on that version or later that > supercedes the plain dependency. No, it is up to the library package to declare in it's shlibs file that packages using it should depend on at minimum the latest version of the library that added new symbols. > Specify the strict version ahead of shlib:Depends and dpkg-shlibdeps > does the right thing. Thats a hack. Another workaround for broken shlibs is debian/shlibs.local. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
On 2008-12-09, Paul Wise <[EMAIL PROTECTED]> wrote: >> I doubt that - merely adding a new symbol is NOT a bug, let alone >> release-critical. > > Right, but not bumping shlibs at the same time is an RC bug AFAIK. I agree. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
On Tue, 9 Dec 2008 16:06:46 + Neil Williams <[EMAIL PROTECTED]> wrote: > The bug only arises if symbols are removed or function prototypes are > changed in existing symbols. > > > http://qa.debian.org/cgi-bin/mole/seedsymbols/.raw/seedsymbols/libflac++6_i386 > > Then a new line gets added for a symbol that only occurs in that > version. > > > Please file a bug about this. > > Please don't - it is not a bug. > > If it was, we'd be on libglib.so.7787.0.0 by now. See the list here: http://library.gnome.org/devel/glib/unstable/ Index of new symbols in 2.2 Index of new symbols in 2.4 Index of new symbols in 2.6 Index of new symbols in 2.8 Index of new symbols in 2.10 Index of new symbols in 2.12 Index of new symbols in 2.14 Index of new symbols in 2.16 Index of new symbols in 2.18 Index of new symbols in 2.20 Adding a new function (or several hundred new functions) has absolutely ZERO impact on the SONAME as long as the new functions do not overlap existing functions, change existing functions or require any changes elsewhere in the library that remove or modify existing symbols. Cyril, we need to sort this out for that RC bug that doesn't exist but which you raised the severity - adding a new symbol is NOT a bug, as long as it is done properly (as above). It is up to the package using the library to build-depend on the right version and use a strict dependency on that version or later that supercedes the plain dependency. i.e. exactly what I recommended for this package. Specify the strict version ahead of shlib:Depends and dpkg-shlibdeps does the right thing. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpm6SKbxPz7z.pgp Description: PGP signature
Re: Listing dependencies with specific versions
Neil Williams <[EMAIL PROTECTED]> (09/12/2008): > > Looks like you just found an RC bug in libflac++6 - includes new > > symbols in version 1.2.1-1 according to mole but the shlibs does not > > depend on that version: > > That is not a bug - the package building against it merely has to > require that version. That is. > The bug only arises if symbols are removed or function prototypes are > changed in existing symbols. Wrong. > > Please file a bug about this. > > Please don't - it is not a bug. Please do. > If it was, we'd be on libglib.so.7787.0.0 by now. You *do* understand the concept of SONAME and shlibs, right? You *do* understand that those are different things, right? Given some RC bugs against some of your packages, I start doubting it. Too bad you're being so vocal on this list, and so self-confident. > > Hopefully more libraries will adopt the new dpkg symbols stuff so > > that this can be detected and fixed more often. > > The fix is only necessary if the symbol has CHANGED - added symbols > can be managed perfectly well without a SONAME bump. Again, wrong. Mraw, KiBi. signature.asc Description: Digital signature
Re: Listing dependencies with specific versions
Neil Williams <[EMAIL PROTECTED]> (09/12/2008): > > Short version: “Fix your shlibs.” > > Cyril, we've had this discussion before - merely adding symbols does > NOT require a SONAME bump. Neil, read. Mraw, KiBi. signature.asc Description: Digital signature
Re: Listing dependencies with specific versions
On Tue, 9 Dec 2008 22:18:01 +0900 "Paul Wise" <[EMAIL PROTECTED]> wrote: > On Tue, Dec 9, 2008 at 9:40 PM, Andy Hawkins <[EMAIL PROTECTED]> > wrote: > > > New symbols. It specifically has support for embedding images into > > the FLAC file. This was introduced in 1.2. > > Looks like you just found an RC bug in libflac++6 - includes new > symbols in version 1.2.1-1 according to mole but the shlibs does not > depend on that version: That is not a bug - the package building against it merely has to require that version. The bug only arises if symbols are removed or function prototypes are changed in existing symbols. > http://qa.debian.org/cgi-bin/mole/seedsymbols/.raw/seedsymbols/libflac++6_i386 Then a new line gets added for a symbol that only occurs in that version. > Please file a bug about this. Please don't - it is not a bug. If it was, we'd be on libglib.so.7787.0.0 by now. > > Hopefully more libraries will adopt the new dpkg symbols stuff so that > this can be detected and fixed more often. The fix is only necessary if the symbol has CHANGED - added symbols can be managed perfectly well without a SONAME bump. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpWhViwiRDdZ.pgp Description: PGP signature
Re: Listing dependencies with specific versions
On Wed, Dec 10, 2008 at 1:03 AM, Neil Williams <[EMAIL PROTECTED]> wrote: > Cyril, we've had this discussion before - merely adding symbols does > NOT require a SONAME bump. We are not talking about SONAME bumps, but shlib bumps. > Take a look at glib2.0, libgtk+2.0 and libqof1 - symbols are added all > the time and all that is needed is a versioned build-depends and a > versioned runtime shlib dependency. Right. > I doubt that - merely adding a new symbol is NOT a bug, let alone > release-critical. Right, but not bumping shlibs at the same time is an RC bug AFAIK. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
On Tue, 9 Dec 2008 16:51:50 +0100 Cyril Brulebois <[EMAIL PROTECTED]> wrote: > Andy Hawkins <[EMAIL PROTECTED]> (09/12/2008): > > > Please file a bug about this. > > > > Umm, I'll try. I'm not sure exactly what that bug report should say! > > Kind of new to all this Debian packaging stuff (as of this time last > > week I knew nothing about it!). > > Short version: “Fix your shlibs.” > > Slightly longer version: “Remember to bump your shlibs whenever > symbols get added. Please fix.” > > People that maintain libraries should be able to cope with the shorter > version. If they don't, they probably shouldn't maintain libraries, or > should be mentored for that particular matter. Cyril, we've had this discussion before - merely adding symbols does NOT require a SONAME bump. Take a look at glib2.0, libgtk+2.0 and libqof1 - symbols are added all the time and all that is needed is a versioned build-depends and a versioned runtime shlib dependency. > In that case, one would be pretty welcome to check one's findings > against the packages that are actually in the archive. In this > particular case, as pointed out by Paul, the bug is present in the > packages shipped by Debian, so let's report it. I doubt that - merely adding a new symbol is NOT a bug, let alone release-critical. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgp0XBaRKg8ap.pgp Description: PGP signature
Re: Listing dependencies with specific versions
Andy Hawkins <[EMAIL PROTECTED]> (09/12/2008): > > Please file a bug about this. > > Umm, I'll try. I'm not sure exactly what that bug report should say! > Kind of new to all this Debian packaging stuff (as of this time last > week I knew nothing about it!). Short version: “Fix your shlibs.” Slightly longer version: “Remember to bump your shlibs whenever symbols get added. Please fix.” People that maintain libraries should be able to cope with the shorter version. If they don't, they probably shouldn't maintain libraries, or should be mentored for that particular matter. > I should add at this point that the package I'm using is one I > compiled myself, not an 'official' Debian package. Can't remember > whether it came from Debian or whether I compiled up the .debs direct > from the FLAC sources. In that case, one would be pretty welcome to check one's findings against the packages that are actually in the archive. In this particular case, as pointed out by Paul, the bug is present in the packages shipped by Debian, so let's report it. Mraw, KiBi. signature.asc Description: Digital signature
Re: Listing dependencies with specific versions
Hi, In article <[EMAIL PROTECTED]>, Paul Wise<[EMAIL PROTECTED]> wrote: > On Tue, Dec 9, 2008 at 9:40 PM, Andy Hawkins <[EMAIL PROTECTED]> wrote: > >> New symbols. It specifically has support for embedding images into the FLAC >> file. This was introduced in 1.2. > > Looks like you just found an RC bug in libflac++6 - includes new > symbols in version 1.2.1-1 according to mole but the shlibs does not > depend on that version: > > http://qa.debian.org/cgi-bin/mole/seedsymbols/.raw/seedsymbols/libflac++6_i386 > > Please file a bug about this. Umm, I'll try. I'm not sure exactly what that bug report should say! Kind of new to all this Debian packaging stuff (as of this time last week I knew nothing about it!). I should add at this point that the package I'm using is one I compiled myself, not an 'official' Debian package. Can't remember whether it came from Debian or whether I compiled up the .debs direct from the FLAC sources. Is that likely to make a difference? Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
Eugene V. Lyubimkin <[EMAIL PROTECTED]> (09/12/2008):
> > package-has-a-duplicate-relation depends: libflac++6, libflac++6 (>= 1.2.1)
>
> According to the man dpkg-gencontrol, just place 'libflac++6(>=1.2.1)'
> before the '${shlibs:Depends}', and dpkg-control with throw away less
> strong dependency.
Wrong way to go. Fix libflac (as Paul explained) instead.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: Listing dependencies with specific versions
On Tue, Dec 9, 2008 at 10:18 PM, Paul Wise <[EMAIL PROTECTED]> wrote: > Please file a bug about this. I forgot to ask you to ask the release team for binNMUs for the packages using those symbols once the shlibs is fixed. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
On Tue, Dec 9, 2008 at 9:40 PM, Andy Hawkins <[EMAIL PROTECTED]> wrote: > New symbols. It specifically has support for embedding images into the FLAC > file. This was introduced in 1.2. Looks like you just found an RC bug in libflac++6 - includes new symbols in version 1.2.1-1 according to mole but the shlibs does not depend on that version: http://qa.debian.org/cgi-bin/mole/seedsymbols/.raw/seedsymbols/libflac++6_i386 Please file a bug about this. Hopefully more libraries will adopt the new dpkg symbols stuff so that this can be detected and fixed more often. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
Andy Hawkins wrote:
> Hi all,
>
> I'm in the process of building my first package. Most of the dependencies
> generated by ${shlibs:Depends} are fine for the package, but I need to force
> the version of one particular component.
>
> So I've put
>
> Depends: ${shlibs:Depends}, ${misc:Depends}, libflac++6(>=1.2.1)
>
> in the 'control' file. This causes Lintian to issue a warning:
>
> package-has-a-duplicate-relation depends: libflac++6, libflac++6 (>= 1.2.1)
According to the man dpkg-gencontrol, just place 'libflac++6(>=1.2.1)' before
the '${shlibs:Depends}', and dpkg-control with throw away less strong
dependency.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
Ukrainian C++ Developer, Debian APT contributor
signature.asc
Description: OpenPGP digital signature
Re: Listing dependencies with specific versions
Hi, In article <[EMAIL PROTECTED]>, Neil Williams<[EMAIL PROTECTED]> wrote: > dpkg-shlibdeps appears to disagree - either the symbols in FLAC are > wrong or your suspicion could be wrong. Are you talking about new > symbols in the FLAC library or bug fixes in existing functions? New symbols. It specifically has support for embedding images into the FLAC file. This was introduced in 1.2. My app correctly detects this support at compile time. If it is compiled against a version of FLAC before 1.2, it will not embed pictures. If it see a version >= 1.2 then it will. What I'm trying to avoid is a packaged compiled against the flac-dev with the picture support in, being installed on a system where the installed libflac is <= 1.2 Hope that makes sense? Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
Hi, In article <[EMAIL PROTECTED]>, Neil Williams<[EMAIL PROTECTED]> wrote: > This "component" is a shared library and therefore a build dependency. > If you are going to force a particular version, you should do it in > Build-Depends. > dpkg-shlibdeps will then work out the rest using any symbols files that > may exist.=20 Ah Ok. So I should list the version in Build-depends, and then $(shlibs:Depends) will do the 'right' thing? > But you also need to answer Paul's question - why are you doing this? Answered in response to his post. Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
On Tue, 9 Dec 2008 11:58:29 + (UTC) Andy Hawkins <[EMAIL PROTECTED]> wrote: > >> I need to force the version of one particular component. > > > > Why is that? > > Because that version of FLAC includes extra functionality that is > detected at compile time. Then it is a build-dependency issue - ensure you have specified that version in Build-Depends. > If I compile a binary against the newer > FLAC libraries, then I suspect that binary will fail to run with the > old ones because this functionality isn't present. dpkg-shlibdeps appears to disagree - either the symbols in FLAC are wrong or your suspicion could be wrong. Are you talking about new symbols in the FLAC library or bug fixes in existing functions? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpjV0kM3zgJP.pgp Description: PGP signature
Re: Listing dependencies with specific versions
Hi, In article <[EMAIL PROTECTED]>, Paul Wise<[EMAIL PROTECTED]> wrote: > On Tue, Dec 9, 2008 at 7:02 PM, Andy Hawkins <[EMAIL PROTECTED]> wrote: > >> I need to force the version of one particular component. > > Why is that? Because that version of FLAC includes extra functionality that is detected at compile time. If I compile a binary against the newer FLAC libraries, then I suspect that binary will fail to run with the old ones because this functionality isn't present. I originally started packaging my application for Debian just so that I could distribute a binary package myself (and obviously a source package should anyone want to build it). However, if it is useful and can be added to the archive proper then so much the better. Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
On Tue, 9 Dec 2008 10:02:25 + (UTC)
Andy Hawkins <[EMAIL PROTECTED]> wrote:
> I'm in the process of building my first package. Most of the
> dependencies generated by ${shlibs:Depends} are fine for the package,
> but I need to force the version of one particular component.
This "component" is a shared library and therefore a build dependency.
If you are going to force a particular version, you should do it in
Build-Depends.
dpkg-shlibdeps will then work out the rest using any symbols files that
may exist.
But you also need to answer Paul's question - why are you doing this?
If your package needs >= 1.2.1 (and there should be spaces in that
string) then it check for that version during the build. IIRC you then
put the string before shlib:Depends -
e.g. for one of my upstream projects (not yet in Debian)
Depends: libestron0 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
That is a different use case - where the Depends is added to an
internal package to ensure that both are upgraded together. (Policy 8.5)
> 1. Is this an acceptable method of listing the required libraries, or
> should I list all of them individually?
No - extra depends on debian/control should be those that are not
calculated by shlib:Depends. You cannot replace shlib:Depends with a
fixed list.
> 2. If this is acceptable, will having two 'dependencies' make it do
> the right thing?
No.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpHeMWYVxPhc.pgp
Description: PGP signature
Re: Listing dependencies with specific versions
On Tue, Dec 9, 2008 at 7:02 PM, Andy Hawkins <[EMAIL PROTECTED]> wrote: > I need to force the version of one particular component. Why is that? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
