Nikita V. Youshchenko yo...@debian.org (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 bug
Nikita V. Youshchenko yo...@debian.org 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
Steve Langasek vor...@debian.org 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
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
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
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
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 same
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 versions of the same
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 same
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 that
* 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 library
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 change the
Nikita V. Youshchenko yo...@debian.org 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
On Sun, Sep 06, 2009 at 11:26:20AM -0700, Russ Allbery wrote:
Nikita V. Youshchenko yo...@debian.org 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
On Sun, Sep 06 2009, Russ Allbery wrote:
Nikita V. Youshchenko yo...@debian.org 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
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
Manoj Srivastava sriva...@debian.org 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
18 matches
Mail list logo
