Manoj Srivastava <[EMAIL PROTECTED]> writes:
> On 25 May 2006, Goswin von Brederlow uttered the following:
>
>> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>>
>>> I would say, off hand, that section 8.2 is for people who want
>>> to provide a shared library for other packages, with a stable ABI,
On 25 May 2006, Goswin von Brederlow uttered the following:
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>
>> I would say, off hand, that section 8.2 is for people who want
>> to provide a shared library for other packages, with a stable ABI,
>> and a development package to facilitate linking
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> I would say, off hand, that section 8.2 is for people who want
> to provide a shared library for other packages, with a stable ABI,
> and a development package to facilitate linking to their
> library. There are certain hoops we must jump i
Thomas Girard <[EMAIL PROTECTED]> writes:
> Selon Goswin von Brederlow <[EMAIL PROTECTED]>:
>> Debian policy says:
>>
>> | 8.2 Run-time support programs
>> |
>> | If your package has some run-time support programs which use the
>> | shared library you must not put them in the shared library
>> | p
On 25 May 2006, Adam Borowski told this:
> On Tue, May 23, 2006 at 09:42:03PM -0500, Manoj Srivastava wrote:
>> On 23 May 2006, Goswin von Brederlow stated:
>>> To me it sounds like you are. You provide a shared object file in
>>> a public place so other people can link their binaries against
>>>
> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> If the library is only internal then this falls under 10.2 I think,
> which is only a SHOULD diretive.
You're right. This falls under 10.2 and as I mentioned before, moving the
library to a subdirectory of /usr/lib is a pain.
> The bug tho
Ganesan Rajagopal <[EMAIL PROTECTED]> writes:
>> "Manoj Srivastava <[EMAIL PROTECTED]> writes:
>
>> I am not sure the sections need clarification, inasmuch as
>> they do not really apply to setools. I might clarify that 8.2 is
>> meant for packages that provide shared libraries for g
On Tue, May 23, 2006 at 09:42:03PM -0500, Manoj Srivastava wrote:
> On 23 May 2006, Goswin von Brederlow stated:
> > To me it sounds like you are. You provide a shared object file in a
> > public place so other people can link their binaries against
> > it. What else is a shared library? Does it ma
Selon Goswin von Brederlow <[EMAIL PROTECTED]>:
> Debian policy says:
>
> | 8.2 Run-time support programs
> |
> | If your package has some run-time support programs which use the
> | shared library you must not put them in the shared library
> | package. If you do that then you won't be able to ins
> "Manoj Srivastava <[EMAIL PROTECTED]> writes:
> I am not sure the sections need clarification, inasmuch as
> they do not really apply to setools. I might clarify that 8.2 is
> meant for packages that provide shared libraries for general use by
> other package developers, and it im
On 23 May 2006, Goswin von Brederlow stated:
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>
>> On 22 May 2006, Goswin von Brederlow stated:
>>
>>> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>>>
On 22 May 2006, Goswin von Brederlow outgrape:
> I think that Policy 8.2 is fully applicabl
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> On 22 May 2006, Goswin von Brederlow stated:
>
>> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>>
>>> On 22 May 2006, Goswin von Brederlow outgrape:
I think that Policy 8.2 is fully applicable to your package
then. It is a MUST directive so
On 22 May 2006, Goswin von Brederlow stated:
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>
>> On 22 May 2006, Goswin von Brederlow outgrape:
>>> I think that Policy 8.2 is fully applicable to your package
>>> then. It is a MUST directive so your unwillingness to allow
>>> multiple versions of y
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> On 22 May 2006, Goswin von Brederlow outgrape:
>> I think that Policy 8.2 is fully applicable to your package then. It
>> is a MUST directive so your unwillingness to allow multiple versions
>> of your library to coexist does not affect the violation.
On 22 May 2006, Goswin von Brederlow outgrape:
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>
>> On 19 May 2006, Goswin von Brederlow outgrape:
>>
>> setools is in the list, and contains libraries that it uses
>> itself, but does not break it up into multiple installed
>> packages. Setools is mo
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> On 19 May 2006, Goswin von Brederlow outgrape:
>
> setools is in the list, and contains libraries that it uses
> itself, but does not break it up into multiple installed
> packages. Setools is moving rapidly rnough that I do not intend to
>
On 19 May 2006, Goswin von Brederlow outgrape:
setools is in the list, and contains libraries that it uses
itself, but does not break it up into multiple installed
packages. Setools is moving rapidly rnough that I do not intend to
support multiple versions of the libraries until things
"Martijn van Oosterhout" <[EMAIL PROTECTED]> writes:
> On 5/21/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>> For multiarch this will be an inconvenience though as people might
>> want to install both 32bit and 64bit of a -dev package. For such small
>> scripts spliting them into extra pac
On 5/21/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
For multiarch this will be an inconvenience though as people might
want to install both 32bit and 64bit of a -dev package. For such small
scripts spliting them into extra packages seems wrong but then you
have to use alternatives or simi
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>
>> Hi,
>>
>> Debian policy says:
>>
>> | 8.2 Run-time support programs
>> |
>> | If your package has some run-time support programs which use the
>> | shared library you must not put them in the s
Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> Hi,
>
> Debian policy says:
>
> | 8.2 Run-time support programs
> |
> | If your package has some run-time support programs which use the
> | shared library you must not put them in the shared library
> | package. If you do that then you won't be
Simon Huggins <[EMAIL PROTECTED]> writes:
> On Fri, May 19, 2006 at 07:56:54PM +0200, Goswin von Brederlow wrote:
>> Aurelien Jarno <[EMAIL PROTECTED]> writes:
>> > I don't see why this could be a problem for multiarch. The library is
>> > only used by the binary which is the same package, so they
Al Stone <[EMAIL PROTECTED]> writes:
>> If the library is only used for binary packages from the same source
>> [which always get updated together] then why not put it in
>> /usr/lib/package/ and make it not public?
>
> This could be done for the qprof package. I'm not sure that qualifies
> as an
On Fri, May 19, 2006 at 07:56:54PM +0200, Goswin von Brederlow wrote:
> Aurelien Jarno <[EMAIL PROTECTED]> writes:
> > I don't see why this could be a problem for multiarch. The library is
> > only used by the binary which is the same package, so they are always
> > in sync.
> libfoo:i386 contains
On Fri, 2006-05-19 at 18:44 +0200, Goswin von Brederlow wrote:
> Debian policy says:
>
> | 8.2 Run-time support programs
> |
> | If your package has some run-time support programs which use the
> | shared library you must not put them in the shared library
> | package. If you do that then you won
Aurelien Jarno <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow wrote:
>> Aurelien Jarno <[EMAIL PROTECTED]> writes:
>>
>>> Goswin von Brederlow wrote:
Hi,
Debian policy says:
| 8.2 Run-time support programs
| | If your package has some run-time support programs which use the
Goswin von Brederlow wrote:
Aurelien Jarno <[EMAIL PROTECTED]> writes:
Goswin von Brederlow wrote:
Hi,
Debian policy says:
| 8.2 Run-time support programs
| | If your package has some run-time support programs which use the
| shared library you must not put them in the shared library
| package
Christoph Berg <[EMAIL PROTECTED]> writes:
> Re: Goswin von Brederlow 2006-05-19 <[EMAIL PROTECTED]>
>> The line below looks for all packages with a *.so.* file in (/usr)/lib
>> and a file in (/usr)/bin. The assumption is that anything with a
>> *.so.* file in the system library dirs is a library
Aurelien Jarno <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow wrote:
>> Hi,
>> Debian policy says:
>> | 8.2 Run-time support programs
>> | | If your package has some run-time support programs which use the
>> | shared library you must not put them in the shared library
>> | package. If you do
Aurelien Jarno <[EMAIL PROTECTED]> wrote:
> Frank Küster wrote:
>> Aurelien Jarno <[EMAIL PROTECTED]> wrote:
>>
libc6 GNU Libc Maintainers
>>> For this one, please talk with the ftpmasters. Such a change has
>>> already been done, but rejected from the NEW queue.
>>
Frank Küster wrote:
Aurelien Jarno <[EMAIL PROTECTED]> wrote:
libc6 GNU Libc Maintainers
For this one, please talk with the ftpmasters. Such a change has
already been done, but rejected from the NEW queue.
Can you quote the reasons?
Yes, please see:
http://lists.debian.
Aurelien Jarno <[EMAIL PROTECTED]> wrote:
>> libc6 GNU Libc Maintainers
>
> For this one, please talk with the ftpmasters. Such a change has
> already been done, but rejected from the NEW queue.
Can you quote the reasons?
Regards, Frank
--
Frank Küster
Single Molecule Spectro
Re: Goswin von Brederlow 2006-05-19 <[EMAIL PROTECTED]>
> The line below looks for all packages with a *.so.* file in (/usr)/lib
> and a file in (/usr)/bin. The assumption is that anything with a
> *.so.* file in the system library dirs is a library package and those
> may not have files in (/usr)/
Goswin von Brederlow wrote:
Hi,
Debian policy says:
| 8.2 Run-time support programs
|
| If your package has some run-time support programs which use the
| shared library you must not put them in the shared library
| package. If you do that then you won't be able to install several
| versions
Hi,
Debian policy says:
| 8.2 Run-time support programs
|
| If your package has some run-time support programs which use the
| shared library you must not put them in the shared library
| package. If you do that then you won't be able to install several
| versions of the shared library without g
35 matches
Mail list logo
