Emilio Pozuelo Monfort writes:
> On 13/07/10 04:11, Russ Allbery wrote:
>> +
>> + The run-time shared library must be placed in a package
>> + whose name changes whenever the SONAME of the shared
>> + library changes. This allows several versions of the shared
>> + librar
On Sun, Jul 18, 2010 at 18:27:33 +0200, Emilio Pozuelo Monfort wrote:
> On 13/07/10 04:11, Russ Allbery wrote:
[...]
> > +
> > + Run-time shared libraries
> > +
> > +
> > + The run-time shared library must be placed in a package
> > + whose name changes whenever the SONAME of th
Hi,
On 13/07/10 04:11, Russ Allbery wrote:
> Russ Allbery writes:
>
>> There was a lot of background information missing from Policy, which in
>> my opinion made it unnecessarily difficult to understand the motivation
>> and implications of the various Policy requirements. Here's a first
>> dra
On Mon, 12 Jul 2010, Russ Allbery wrote:
> Russ Allbery writes:
>
> > There was a lot of background information missing from Policy, which in
> > my opinion made it unnecessarily difficult to understand the motivation
> > and implications of the various Policy requirements. Here's a first
> > dr
Russ Allbery writes:
> There was a lot of background information missing from Policy, which in
> my opinion made it unnecessarily difficult to understand the motivation
> and implications of the various Policy requirements. Here's a first
> draft of a patch to add much more information about how
Steve Langasek writes:
> On Thu, Jul 08, 2010 at 10:10:51AM -0700, Russ Allbery wrote:
>> -
>> -Run-time shared libraries
>> +
>> +A shared library must be uniquely identified by an SONAME
>> +attribute stored in its dynamic section.
> This wording is going to cause probl
Mike Hommey writes:
> Please note that while not having a version in the SONAME didn't work
> well with shlibs, it does work well with symbols file.
> Now, I've been wondering for a while if we shouldn't relax our rules on
> SONAMEs considering the above, for libraries whose ABI doesn't change i
Raphael Hertzog writes:
> I'm not sure the ldconfig bit is relevant here. Simply state that the
> symlink must be provided by the package (created is confusing, it might
> mean created by the postinst through the ldconfig call). If you want to
> speak of ldconfig you can put it in a footnote sayi
On Sat, Jul 10, 2010 at 12:36:14PM -0700, Steve Langasek wrote:
> It's not that these libraries will never have incompatible ABI changes, it's
> that they encode the ABI information in a non-standard way - the '4' in
> libnspr4 and the '3' in libnss3 do represent the sover, they just do it in a
> m
On Fri, Jul 09, 2010 at 05:09:05PM +0200, Mike Hommey wrote:
> On Thu, Jul 08, 2010 at 10:10:51AM -0700, Russ Allbery wrote:
> > Russ Allbery writes:
> > > I read through the shared library sections of Policy a few times last
> > > night and can't find anywhere where Policy unambiguously recommen
On Thu, Jul 08, 2010 at 10:10:51AM -0700, Russ Allbery wrote:
> -
> - Run-time shared libraries
> +
> + A shared library must be uniquely identified by an SONAME
> + attribute stored in its dynamic section.
This wording is going to cause problems down the line.
$ objdump -
Raphael Hertzog writes:
> On Thu, 08 Jul 2010, Russ Allbery wrote:
> > + A shared library must be uniquely identified by an SONAME
>
> s/an/a/ ? (I saw it several times, sounds odd to me but maybe I miss
> something)
Like Russ, it sounds fine to me. That's probably because we pronounce
the ini
On Thu, Jul 08, 2010 at 10:10:51AM -0700, Russ Allbery wrote:
> Russ Allbery writes:
>
> > I read through the shared library sections of Policy a few times last
> > night and can't find anywhere where Policy unambiguously recommends
> > always including a version in SONAME for public libraries.
On Thu, 08 Jul 2010, Russ Allbery wrote:
> Objections, sections, or other review?
Looks mostly good, I have some fixes and suggestions below.
> -
> - Run-time shared libraries
> +
> + A shared library must be uniquely identified by an SONAME
s/an/a/ ? (I saw it several times,
Russ Allbery writes:
> I read through the shared library sections of Policy a few times last
> night and can't find anywhere where Policy unambiguously recommends
> always including a version in SONAME for public libraries. If you don't
> have a version, you can't represent the library in the sh
"Giacomo A. Catenazzi" writes:
> Russ Allbery wrote:
>> I read through the shared library sections of Policy a few times last
>> night and can't find anywhere where Policy unambiguously recommends
>> always including a version in SONAME for public libraries. If you
>> don't have a version, you c
Russ Allbery wrote:
Package: debian-policy
Version: 3.8.0.1
Severity: minor
I read through the shared library sections of Policy a few times last night
and can't find anywhere where Policy unambiguously recommends always
including a version in SONAME for public libraries. If you don't have a
ve
Package: debian-policy
Version: 3.8.0.1
Severity: minor
I read through the shared library sections of Policy a few times last night
and can't find anywhere where Policy unambiguously recommends always
including a version in SONAME for public libraries. If you don't have a
version, you can't repre
18 matches
Mail list logo
