Nikita V. Youshchenko (06/09/2009):
> Is libpkg-guide an official debian document these days?
FSVO “official”:
- http://packages.debian.org/sid/libpkg-guide
- http://bugs.debian.org/libpkg-guide
Mraw,
KiBi.
signature.asc
Description: Digital signature
On Sun, Sep 06, 2009 at 01:50:45PM +0200, Julien Cristau wrote:
> On Sun, Sep 6, 2009 at 15:14:21 +0400, Nikita V. Youshchenko wrote:
>
> > As of today, debian does not contain this bug, because ffmpeg with this
> > brakage happened not to be uploaded yet to debian. However, once it is,
> > the
Steve Langasek writes:
>> We have done this in the past in Debian without changing the SONAME in
>> places where compatibility of SONAME with other distributions is
>> important. Specifically, libkrb53 removed several private symbols and we
>> didn't change the SONAME. *However*, if you're thi
"Nikita V. Youshchenko" writes:
> As of today, debian does not contain this bug, because ffmpeg with this
> brakage happened not to be uploaded yet to debian. However, once it is,
> the bug will be in debian, and will have to be handled somehow.
mplayer is really meant to be using the internal
Manoj Srivastava writes:
> On Sun, Sep 06 2009, Russ Allbery wrote:
>> We have done this in the past in Debian without changing the SONAME in
>> places where compatibility of SONAME with other distributions is
>> important. Specifically, libkrb53 removed several private symbols and
>> we didn't
Steve Langasek wrote:
> And if the symbols in question were exported in a header (else how did
> mplayer come to depend on them?),
The package could have defined the prototype before using it. That's a real live
scenario, see e.g. #542216 (hopefully it's not very frequent...).
Emilio
signature
On Sun, Sep 06 2009, Russ Allbery wrote:
> "Nikita V. Youshchenko" writes:
>
>> This does not help in a corner case.
>
>> Issue I am looking at is:
>> - a library used to export a symbol, it was visible in objdump -T output,
>> - at some point, upstream decides that this symbol should be removed,
On Sun, Sep 06, 2009 at 11:26:20AM -0700, Russ Allbery wrote:
> "Nikita V. Youshchenko" writes:
> > This does not help in a corner case.
> > Issue I am looking at is:
> > - a library used to export a symbol, it was visible in objdump -T output,
> > - at some point, upstream decides that this sym
"Nikita V. Youshchenko" writes:
> This does not help in a corner case.
> Issue I am looking at is:
> - a library used to export a symbol, it was visible in objdump -T output,
> - at some point, upstream decides that this symbol should be removed,
> claiming that "it was not ever included in any
On Sun, Sep 06, 2009 at 03:45:38PM +, Florian Weimer wrote:
> * Julien Cristau:
> >> Yes, it's an RC bug. If you break the API and/or ABI, you need to change
> >> the
> >> package name and the SONAME.
> > AFAIK the rule is "if you break ABI, you MUST change the package name and
> > SHOULD ch
* Julien Cristau:
>> Yes, it's an RC bug. If you break the API and/or ABI, you need to change the
>> package name and the SONAME.
>>
> AFAIK the rule is "if you break ABI, you MUST change the package name and
> SHOULD change the SONAME".
It's still possible to work around that by not providing a
On Sun, Sep 6, 2009 at 15:14:21 +0400, Nikita V. Youshchenko wrote:
> As of today, debian does not contain this bug, because ffmpeg with this
> brakage happened not to be uploaded yet to debian. However, once it is,
> the bug will be in debian, and will have to be handled somehow.
>
So when th
> On Sun, Sep 6, 2009 at 12:50:59 +0200, Emilio Pozuelo Monfort wrote:
> > Nikita V. Youshchenko wrote:
> > > Hi
> > >
> > > Is there an statement in Debian Policy that explicitly requires
> > > higher version of a shared library package to be
> > > backwards-binary-compatible with previous versio
On Sun, Sep 06, 2009 at 02:58:02PM +0400, Nikita V. Youshchenko wrote:
> > Nikita V. Youshchenko wrote:
> > > Hi
> > >
> > > Is there an statement in Debian Policy that explicitly requires higher
> > > version of a shared library package to be backwards-binary-compatible
> > > with previous version
On Sun, Sep 6, 2009 at 12:50:59 +0200, Emilio Pozuelo Monfort wrote:
> Nikita V. Youshchenko wrote:
> > Hi
> >
> > Is there an statement in Debian Policy that explicitly requires higher
> > version of a shared library package to be backwards-binary-compatible with
> > previous versions of the
> Nikita V. Youshchenko wrote:
> > Hi
> >
> > Is there an statement in Debian Policy that explicitly requires higher
> > version of a shared library package to be backwards-binary-compatible
> > with previous versions of the same package?
> >
> > I mean, is a situation when after library package up
Nikita V. Youshchenko wrote:
> Hi
>
> Is there an statement in Debian Policy that explicitly requires higher
> version of a shared library package to be backwards-binary-compatible with
> previous versions of the same package?
>
> I mean, is a situation when after library package upgrade local
Hi
Is there an statement in Debian Policy that explicitly requires higher
version of a shared library package to be backwards-binary-compatible with
previous versions of the same package?
I mean, is a situation when after library package upgrade local binaries
stops working because of missing
18 matches
Mail list logo
