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
| package. If you do
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 in
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 to their
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,
and a
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 matter
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 general use by
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 though
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
it. What
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 implies a
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 install
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 your unwillingness
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 applicable to your package
then.
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
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 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 moving rapidly
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 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 your library to
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
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 packages seems
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 able to
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 shared library
|
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
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
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)/bin.
Aurelien Jarno [EMAIL PROTECTED] wrote:
libc6 GNU Libc Maintainers debian-glibc@lists.debian.org
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
Frank Küster wrote:
Aurelien Jarno [EMAIL PROTECTED] wrote:
libc6 GNU Libc Maintainers debian-glibc@lists.debian.org
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,
Aurelien Jarno [EMAIL PROTECTED] wrote:
Frank Küster wrote:
Aurelien Jarno [EMAIL PROTECTED] wrote:
libc6 GNU Libc Maintainers
debian-glibc@lists.debian.org
For this one, please talk with the ftpmasters. Such a change has
already been done, but rejected from the NEW
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 that then you
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 package
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.
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
| shared library you must
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't be
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
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 RC bug,
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 are always
35 matches
Mail list logo
