Bug#347581: debian-policy: Explicitly permit *-headers binary package created from library source package
Russ Allbery r...@debian.org writes: For background here, this bug is about permitting the splitting of the architecture-independent headers for a library into a separate -headers package rather than requiring (which the current Policy wording implies) that they be in the usually architecture-dependent -dev package. [...] This has now been merged for the next release. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#347581: debian-policy: Explicitly permit *-headers binary package created from library source package
On Sat, 2010-06-12 at 13:01 -0700, Russ Allbery wrote: For background here, this bug is about permitting the splitting of the architecture-independent headers for a library into a separate -headers package rather than requiring (which the current Policy wording implies) that they be in the usually architecture-dependent -dev package. Kevin B. McCarty kmcca...@princeton.edu writes: Chris Waters wrote: I would rather see that last sentence modified slightly to allow a little more flexibility. Perhaps changing placed in to placed in or installed by. Or something along those lines. Hmm, how about this? (I can't quite see how to keep it to a single sentence of reasonable length.) If there are development files associated to a shared library, the source package needs to generate a binary development package called librarynamesoversion-dev, or if you prefer only to support one development version at a time, libraryname-dev. Installing the development package must result in installation of all the development files. This change would leave the door open for development files to be split up into separate packages as needed, as long as libwhatever-dev depends upon all of them, either directly or indirectly. This looks good to me. Here's proposed wording. Objections or seconds? diff --git a/policy.sgml b/policy.sgml index 720150d..1e134bb 100644 --- a/policy.sgml +++ b/policy.sgml @@ -5163,11 +5163,20 @@ Replaces: mail-transport-agent headingDevelopment files/heading p - The development files associated to a shared library need to be - placed in a package called - packagevarlibraryname/varvarsoversion/var-dev/package, + If there are development files associated with a shared library, + the source package needs to generate a binary development package + named packagevarlibraryname/varvarsoversion/var-dev/package, or if you prefer only to support one development version at a - time, packagevarlibraryname/var-dev/package. + time, packagevarlibraryname/var-dev/package. Installing + the development package must result in installation of all the + development files necessary for compiling programs against that + shared library.footnote + This wording allows the development files to be split into + several packages, such as a separate architecture-independent + packagevarlibraryname/var-headers/package, provided that + the development package depends on all the required additional + packages. + /footnote /p p Seconded. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Does the turtle move for you? www.kame.net signature.asc Description: This is a digitally signed message part
Bug#347581: debian-policy: Explicitly permit *-headers binary package created from library source package
For background here, this bug is about permitting the splitting of the architecture-independent headers for a library into a separate -headers package rather than requiring (which the current Policy wording implies) that they be in the usually architecture-dependent -dev package. Kevin B. McCarty kmcca...@princeton.edu writes: Chris Waters wrote: I would rather see that last sentence modified slightly to allow a little more flexibility. Perhaps changing placed in to placed in or installed by. Or something along those lines. Hmm, how about this? (I can't quite see how to keep it to a single sentence of reasonable length.) If there are development files associated to a shared library, the source package needs to generate a binary development package called librarynamesoversion-dev, or if you prefer only to support one development version at a time, libraryname-dev. Installing the development package must result in installation of all the development files. This change would leave the door open for development files to be split up into separate packages as needed, as long as libwhatever-dev depends upon all of them, either directly or indirectly. This looks good to me. Here's proposed wording. Objections or seconds? diff --git a/policy.sgml b/policy.sgml index 720150d..1e134bb 100644 --- a/policy.sgml +++ b/policy.sgml @@ -5163,11 +5163,20 @@ Replaces: mail-transport-agent headingDevelopment files/heading p - The development files associated to a shared library need to be - placed in a package called - packagevarlibraryname/varvarsoversion/var-dev/package, + If there are development files associated with a shared library, + the source package needs to generate a binary development package + named packagevarlibraryname/varvarsoversion/var-dev/package, or if you prefer only to support one development version at a - time, packagevarlibraryname/var-dev/package. + time, packagevarlibraryname/var-dev/package. Installing + the development package must result in installation of all the + development files necessary for compiling programs against that + shared library.footnote + This wording allows the development files to be split into + several packages, such as a separate architecture-independent + packagevarlibraryname/var-headers/package, provided that + the development package depends on all the required additional + packages. + /footnote /p p -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#347581: debian-policy: Explicitly permit *-headers binary package created from library source package
On Sat, Jun 12, 2010 at 13:01:57 -0700, Russ Allbery wrote:
diff --git a/policy.sgml b/policy.sgml
index 720150d..1e134bb 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -5163,11 +5163,20 @@ Replaces: mail-transport-agent
headingDevelopment files/heading
p
- The development files associated to a shared library need to be
- placed in a package called
- packagevarlibraryname/varvarsoversion/var-dev/package,
+ If there are development files associated with a shared library,
+ the source package needs to generate a binary development package
+ named packagevarlibraryname/varvarsoversion/var-dev/package,
or if you prefer only to support one development version at a
- time, packagevarlibraryname/var-dev/package.
+ time, packagevarlibraryname/var-dev/package. Installing
+ the development package must result in installation of all the
+ development files necessary for compiling programs against that
+ shared library.footnote
+ This wording allows the development files to be split into
+ several packages, such as a separate architecture-independent
+ packagevarlibraryname/var-headers/package, provided that
+ the development package depends on all the required additional
+ packages.
+ /footnote
/p
p
Seconded.
Cheers,
Julien - who does this for libxmu{,u} and libgl{,u}, at least
signature.asc
Description: Digital signature
Bug#347581: debian-policy: Explicitly permit *-headers binary package created from library source package
On Wed, Jan 11, 2006 at 11:19:05AM -0500, Kevin B. McCarty wrote: Could Policy be amended slightly to explicitly permit library source packages to create a library-headers package containing include files? I would rather see it modified to not forbid it than add a whole paragraph to explicitly permit it. I think the suggested text is much too long. I'm not objecting to the idea; merely the wording. [proposed paragraph elided] Without this or a similar text, it is not clear to me that source packages creating library-headers binary packages are in compliance with Policy, which currently says The development files associated to a shared library need to be placed in a package called librarynamesoversion-dev, or if you prefer only to support one development version at a time, libraryname-dev. I would rather see that last sentence modified slightly to allow a little more flexibility. Perhaps changing placed in to placed in or installed by. Or something along those lines. If you can come up with something like that which allows you to do what you want, without going into excessive and unnecessary detail, I can probably be persuaded to second it. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347581: debian-policy: Explicitly permit *-headers binary package created from library source package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Waters wrote: On Wed, Jan 11, 2006 at 11:19:05AM -0500, Kevin B. McCarty wrote: Without this or a similar text, it is not clear to me that source packages creating library-headers binary packages are in compliance with Policy, which currently says The development files associated to a shared library need to be placed in a package called librarynamesoversion-dev, or if you prefer only to support one development version at a time, libraryname-dev. I would rather see that last sentence modified slightly to allow a little more flexibility. Perhaps changing placed in to placed in or installed by. Or something along those lines. Hmm, how about this? (I can't quite see how to keep it to a single sentence of reasonable length.) If there are development files associated to a shared library, the source package needs to generate a binary development package called librarynamesoversion-dev, or if you prefer only to support one development version at a time, libraryname-dev. Installing the development package must result in installation of all the development files. This change would leave the door open for development files to be split up into separate packages as needed, as long as libwhatever-dev depends upon all of them, either directly or indirectly. - -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDxqxffYxAIk+Dx1ERAq7BAJ45NWQTVTONEpjioHS9MuQ+HfVzuQCfekjQ +0cx8IB0WddGCk+pGVsKTqg= =hcZW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347581: debian-policy: Explicitly permit *-headers binary package created from library source package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: debian-policy Severity: wishlist Version: 3.6.2.2 Hi, Could Policy be amended slightly to explicitly permit library source packages to create a library-headers package containing include files? I am thinking that something like the following could be added between the existing first and second paragraphs of Section 8.4, Development files, http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-dev [begin suggested text] If your library source package includes a large number of header files that are to be installed in /usr/include or subdirectories thereof, it may place them in a binary package called librarynamesoversion-headers or (if you prefer only to support one development version at a time, or if the library API is preserved across different soversions) libraryname-headers. If you do this, the development package must Depend upon the headers package. If the development package is architecture-dependent and the headers package is not, the development package should not require exactly the same version of the headers package in order to prevent problems arising from binary NMUs. [end suggested text] Without this or a similar text, it is not clear to me that source packages creating library-headers binary packages are in compliance with Policy, which currently says The development files associated to a shared library need to be placed in a package called librarynamesoversion-dev, or if you prefer only to support one development version at a time, libraryname-dev. The following library source packages of which I am aware create - -headers packages that are in compliance with the suggested amendment above: . affix-kernel . atlas3 . qt-x11-free (Qt3) . wxwindows2.4 . wxwidgets2.6 The following library source package creates a -headers package that is not quite in compliance: . newlib (has exact version dependency of arch:any -dev package on arch:all -headers package) Some other source packages creating -headers packages to which this suggested policy amendment would not apply: . *-kernel-headers (not created from a library source package) . em8300-headers (ditto) . octave2.1 (the shared libs aren't in /usr/lib, nor does the package tweak ld.so.conf so that they're visible to the runtime linker, so I don't believe this counts as a library source package) . octave2.9 (ditto) CC'ed to debian-devel in case anyone wants to add to or disagree with this suggestion. regards, - -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDxS/5fYxAIk+Dx1ERAnK+AKC9+FmXe/NiDmtpuUU/T7kLcX2SogCgqrQr CQp3MCVPmgLqq6loQfnccwg= =eVUJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347581: debian-policy: Explicitly permit *-headers binary package created from library source package
Kevin B. McCarty [EMAIL PROTECTED] writes: Could Policy be amended slightly to explicitly permit library source packages to create a library-headers package containing include files? I am thinking that something like the following could be added between the existing first and second paragraphs of Section 8.4, Development files, http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-dev [begin suggested text] If your library source package includes a large number of header files that are to be installed in /usr/include or subdirectories thereof, it may place them in a binary package called librarynamesoversion-headers or (if you prefer only to support one development version at a time, or if the library API is preserved across different soversions) libraryname-headers. If you do this, the development package must Depend upon the headers package. If the development package is architecture-dependent and the headers package is not, the development package should not require exactly the same version of the headers package in order to prevent problems arising from binary NMUs. [end suggested text] Without this or a similar text, it is not clear to me that source packages creating library-headers binary packages are in compliance with Policy, which currently says The development files associated to a shared library need to be placed in a package called librarynamesoversion-dev, or if you prefer only to support one development version at a time, libraryname-dev. It's not clear to me that splitting out the headers is actually a good thing (it's very annoying for autobuilders since the corresponding -dev package won't be installable until the new version has been autobuilt), so I certainly don't think policy should endorse it. CC'ed to debian-devel in case anyone wants to add to or disagree with this suggestion. Uh, no it's not. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347581: debian-policy: Explicitly permit *-headers binary package created from library source package
Brian Nelson wrote: It's not clear to me that splitting out the headers is actually a good thing (it's very annoying for autobuilders since the corresponding -dev package won't be installable until the new version has been autobuilt), so I certainly don't think policy should endorse it. It wouldn't be an endorsement, just a permission. It seems to me that policy currently prohibits -headers packages for shared libraries by saying that development files must be in the -dev package. Do you feel -headers packages _should_ be explicitly prohibited? My main motive in making the suggestion is that when the headers are architecture-independent and there are a lot of them, splitting them out into a separate arch:all package can save a lot of archive space. (I don't know what the motive was of the developers who created packages like libqt3-headers, which are arch:any.) Kevin B. McCarty [EMAIL PROTECTED] writes: CC'ed to debian-devel in case anyone wants to add to or disagree with this suggestion. Uh, no it's not. For CC'ed read X-Debbugs-CC'ed. The web archive of the mailing list hasn't been updated since early this morning (as of this writing), but you can see my email in the gated newsgroup, for instance on Google Groups, http://groups.google.com/group/linux.debian.devel . If it isn't showing up to debian-devel email subscribers, something strange is going on (I read the list through the web archive so I don't know whether or not this is the case). regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347581: debian-policy: Explicitly permit *-headers binary package created from library source package
Kevin B. McCarty [EMAIL PROTECTED] writes: Brian Nelson wrote: It's not clear to me that splitting out the headers is actually a good thing (it's very annoying for autobuilders since the corresponding -dev package won't be installable until the new version has been autobuilt), so I certainly don't think policy should endorse it. It wouldn't be an endorsement, just a permission. It seems to me that policy currently prohibits -headers packages for shared libraries by saying that development files must be in the -dev package. Do you feel -headers packages _should_ be explicitly prohibited? Sure, I don't see any advantage to having them. My main motive in making the suggestion is that when the headers are architecture-independent and there are a lot of them, splitting them out into a separate arch:all package can save a lot of archive space. (I don't know what the motive was of the developers who created packages like libqt3-headers, which are arch:any.) Get:1 http://rubeus sid/main libqt3-headers 3:3.3.5-3 [364kB] Fetched 364kB in 1s (226kB/s) I wouldn't call 364kB a lot of saved archive space, and you'd be hard-pressed to find a package with more headers than Qt. Kevin B. McCarty [EMAIL PROTECTED] writes: CC'ed to debian-devel in case anyone wants to add to or disagree with this suggestion. Uh, no it's not. For CC'ed read X-Debbugs-CC'ed. The web archive of the mailing list hasn't been updated since early this morning (as of this writing), but you can see my email in the gated newsgroup, for instance on Google Groups, http://groups.google.com/group/linux.debian.devel . If it isn't showing up to debian-devel email subscribers, something strange is going on (I read the list through the web archive so I don't know whether or not this is the case). Oh, I guess the mail I replied to hadn't been processed by the submit bot then. My mistake. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347581: debian-policy: Explicitly permit *-headers binary package created from library source package
Brian Nelson wrote: Get:1 http://rubeus sid/main libqt3-headers 3:3.3.5-3 [364kB] Fetched 364kB in 1s (226kB/s) I wouldn't call 364kB a lot of saved archive space, and you'd be hard-pressed to find a package with more headers than Qt. I'm actually working on unofficial packages of Geant 4 that might go into Debian if upstream ever clarifies their license situation, and I currently have benjo (sid)[126]:~% ls -l src/GEANT4/geant4-headers_4.8.0-1_all.deb -rw-r--r-- 1 kmccarty kmccarty 1300680 2006-01-11 11:58 src/GEANT4/geant4-headers_4.8.0-1_all.deb but I guess even 11 * (1.3 MB) isn't so much compared to the full archive size. If the general attitude of debian-devel is that this bug should be closed, fine -- I don't have a deep emotional investment in it :-) Although in that case someone may want to file policy bugs against the headers packages I mentioned in the original email. regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347581: debian-policy: Explicitly permit *-headers binary package created from library source package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin B. McCarty [EMAIL PROTECTED] writes: Brian Nelson wrote: It's not clear to me that splitting out the headers is actually a good thing (it's very annoying for autobuilders since the corresponding -dev package won't be installable until the new version has been autobuilt), so I certainly don't think policy should endorse it. It wouldn't be an endorsement, just a permission. It seems to me that policy currently prohibits -headers packages for shared libraries by saying that development files must be in the -dev package. Do you feel -headers packages _should_ be explicitly prohibited? If we do anything, IMO it should be to drop static libraries, in which case in most cases the -dev package could then become arch-all in any case (most -dev packages only contain a static lib as the arch-dependent part). Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFDxVDgVcFcaSW/uEgRAng1AKCi6aD0w2g+GSqBtGE1jvSolcqh3QCgmd5x yGrXmbZdJkAQIW21b0CpHXA= =90u1 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347581: debian-policy: Explicitly permit *-headers binary package created from library source package
On Wed, Jan 11, 2006 at 01:04:44PM -0500, Kevin B. McCarty wrote: benjo (sid)[126]:~% ls -l src/GEANT4/geant4-headers_4.8.0-1_all.deb -rw-r--r-- 1 kmccarty kmccarty 1300680 2006-01-11 11:58 src/GEANT4/geant4-headers_4.8.0-1_all.deb but I guess even 11 * (1.3 MB) isn't so much compared to the full archive size. Are you sure they are architecture-independant ? If the general attitude of debian-devel is that this bug should be closed, fine -- I don't have a deep emotional investment in it :-) Although in that case someone may want to file policy bugs against the headers packages I mentioned in the original email. As far as I am concerned, I have no objections on the -headers packages, provided there exists a -dev package that depends on it and that it is worth the extra Packages lines. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347581: debian-policy: Explicitly permit *-headers binary package created from library source package
Bill Allombert wrote: On Wed, Jan 11, 2006 at 01:04:44PM -0500, Kevin B. McCarty wrote: benjo (sid)[126]:~% ls -l src/GEANT4/geant4-headers_4.8.0-1_all.deb -rw-r--r-- 1 kmccarty kmccarty 1300680 2006-01-11 11:58 src/GEANT4/geant4-headers_4.8.0-1_all.deb but I guess even 11 * (1.3 MB) isn't so much compared to the full archive size. Are you sure they are architecture-independant ? Pretty darn certain. Upstream's build process just copies the header files out of the source code into a single directory at make install time. They are part of the source tree, not auto-generated. Not even any of the #ifdefs are arch-dependent, unless you count #ifdef WIN32 which I think can be safely ignored :-) regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
