John Stamp wrote:
> If that sounds sensible to you, I'll call it settled for now and leave
> the bug open as a reminder.
I'd say that sounds about right.
If it's not asking too much, gently poke upstream to make the SONAME 0
while the lib is unusable. Perhaps for the next release.
If they take
OK. I spoke with upstream.
They are aware of the SONAME version problem and appear interested in
fixing it. And while they don't currently consider libLastFmTools
and the newly-introduced libMoose to be useful for other packages,
they do plan to make them useful in the future.
Given that, I
On Saturday 08 December 2007, Leo "costela" Antunes wrote:
> Just to be extra polite I'd ask upstream if they want people to be
> able to use this lib. Perhaps they haven't really thought about it!
> :-) This could be enough nudging to make them either bump the
> SONAME for the next release or inc
John Stamp wrote:
> The library isn't very useful for other applications; it's for lastfm
> and its bundled plugins: /usr/lib/lastfm/services/*. Also, upstream
> kept the same SONAME version for 1.4.0, but it's incompatible. So
> no, I wouldn't call that stable.
Just to be extra polite I'd as
On Saturday 08 December 2007, Leo costela Antunes wrote:
> The package currently places libLastFmTools.so.1 into /usr/lib. Is
> this library useful for other packages, even if currently no one
> links to it? Is it stable enough for that? If it isn't, perhaps
> upstream's SONAME's wrong and you coul
Package: lastfm
Version: 1:1.3.2.14.dfsg-1
Severity: wishlist
The package currently places libLastFmTools.so.1 into /usr/lib. Is this
library useful for other packages, even if currently no one links to it?
Is it stable enough for that? If it isn't, perhaps upstream's SONAME's
wrong and you could
6 matches
Mail list logo
