Bug#168435: debian-policy: Remove the requirement to install static libraries
* Brendan O'Dea | On Sat, Nov 09, 2002 at 04:25:00PM +0100, Sebastian Rittau wrote: | The main aspect of this proposal is the removed requirement of | including static versions of each library in the corresponding -dev | package. Many modern libraries don't work well as a static library and | usage of static libraries should be deprecated except for a few | specific cases. | | I'd be curious to know of an example of a modern library which doesn't | work well when compiled statically. libc6 fucks up NSS modules, AIUI. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Bug#168435: debian-policy: Remove the requirement to install static libraries
On Thu, Nov 14, 2002 at 09:05:58PM +0100, [EMAIL PROTECTED] wrote: I suggest the following alteration to the policy: +++ policy.sgml 2002-11-09 16:19:08.0 +0100 @@ -5592,12 +5592,12 @@ sect headingLibraries/heading p - In general, libraries must have a shared version in the - library package and a static version in the development - package. The shared version must be compiled with - tt-fPIC/tt, and the static version must not be. In - other words, each source unit ( tt*.c/tt, for example, - for C files) will need to be compiled twice. + All libraries must have a shared version in the + ttlib*/tt package and may have a static version in the + ttlib*-dev/tt package. The shared version must be compiled + with tt-fPIC/tt, and the static version must not be. If a + package has a shared and a static version, each tt*.c/tt + file will need to be compiled twice. /p p In some cases, it is acceptable for a library to be @@ -5625,13 +5625,6 @@ If a library is available only in static form, then it must follow the conventions for a development package. /p - p - All libraries must have a shared version in the - ttlib*/tt package and a static version in the - ttlib*-dev/tt package. The shared version must be - compiled with tt-fPIC/tt, and the static version must - not be. In other words, each tt*.c/tt file will need to - be compiled twice./p p You must specify the gcc option tt-D_REENTRANT/tt Rationale: The removed paragraph was redundant with the first paragraph of the section and was moved there. True. Also the first paragraph is qualified with In general, but not the second, which is confusing. The main aspect of this proposal is the removed requirement of including static versions of each library in the corresponding -dev package. Many modern libraries don't work well as a static library and Try linking your binary executable with -export-dynamic, this help a lot. usage of static libraries should be deprecated except for a few specific cases. ... when building Debian packages. But libraries are not packaged for the benefit of the autobuilders. If you work in a mixed GNU/Linux distributions environment, linking your local executables statically with some libraries is necessary. Also note that static libraries are explicitly not compiled with -fPIC, and so are a bit faster than shared one. Also currently C++ shared libraries are a pain, so static one are useful, etc... This policy change would allow maintainers to decide for themselves, whether a static version of their library is useful, thereby decreasing Your amendment must include guidelines to make such a decision. Experience has shown that a lot of Debian maintainer of library packages need clue about how to manage libraries. Letting them decide for themselves will lead to chaos. Also note that policy treat plug-in differently from libraries. the size of many -dev packages and in turn decreasing download time and archive size. In the rare cases, where a static library is needed and For this goal, you can propose to allow to split -dev packages in -static and -dev packages, -dev recommending -static. -dev containing the headers files and the .so symlink, static the static library. It was done for xlib6g in potato, IIRC. the package maintainer doesn't provide it, the user can either request the inclusion from the maintainer If they run stable, they may wait 18 months that the new release it out. or compile the library his/herself. If you want to follow this path, then your amendment must describe a standard way to rebuild the -dev package *with* the static library included, similar to apt-get source --build, else it will be a very difficult to achieve this and a major annoyance. In conclusion, I hereby object this amendement. Cheers, Bill. [EMAIL PROTECTED] pgpCiWdFm7qfg.pgp Description: PGP signature
Bug#168435: debian-policy: Remove the requirement to install static libraries
On Sat, Nov 09, 2002 at 04:25:00PM +0100, Sebastian Rittau wrote: The main aspect of this proposal is the removed requirement of including static versions of each library in the corresponding -dev package. Many modern libraries don't work well as a static library and usage of static libraries should be deprecated except for a few specific cases. I'd be curious to know of an example of a modern library which doesn't work well when compiled statically. This policy change would allow maintainers to decide for themselves, whether a static version of their library is useful, [...] Whether linking against a static version of a library is useful may only be determined by the requirements of library's users, not the maintainer. --bod
Bug#168435: debian-policy: Remove the requirement to install static libraries
Branden Robinson [EMAIL PROTECTED] writes: On Sat, Nov 09, 2002 at 04:25:00PM +0100, Sebastian Rittau wrote: Package: debian-policy Version: 3.5.7.0 Severity: wishlist I suggest the following alteration to the policy: I object strenuously to this proposal. AOL Me too. /AOL Phil.
Bug#168435: debian-policy: Remove the requirement to install static libraries
Package: debian-policy Version: 3.5.7.0 Severity: wishlist I suggest the following alteration to the policy: --- policy.sgml.old 2002-11-09 14:48:01.0 +0100 +++ policy.sgml 2002-11-09 16:19:08.0 +0100 @@ -5592,12 +5592,12 @@ sect headingLibraries/heading p - In general, libraries must have a shared version in the - library package and a static version in the development - package. The shared version must be compiled with - tt-fPIC/tt, and the static version must not be. In - other words, each source unit ( tt*.c/tt, for example, - for C files) will need to be compiled twice. + All libraries must have a shared version in the + ttlib*/tt package and may have a static version in the + ttlib*-dev/tt package. The shared version must be compiled + with tt-fPIC/tt, and the static version must not be. If a + package has a shared and a static version, each tt*.c/tt + file will need to be compiled twice. /p p In some cases, it is acceptable for a library to be @@ -5625,13 +5625,6 @@ If a library is available only in static form, then it must follow the conventions for a development package. /p - p - All libraries must have a shared version in the - ttlib*/tt package and a static version in the - ttlib*-dev/tt package. The shared version must be - compiled with tt-fPIC/tt, and the static version must - not be. In other words, each tt*.c/tt file will need to - be compiled twice./p p You must specify the gcc option tt-D_REENTRANT/tt Rationale: The removed paragraph was redundant with the first paragraph of the section and was moved there. The main aspect of this proposal is the removed requirement of including static versions of each library in the corresponding -dev package. Many modern libraries don't work well as a static library and usage of static libraries should be deprecated except for a few specific cases. This policy change would allow maintainers to decide for themselves, whether a static version of their library is useful, thereby decreasing the size of many -dev packages and in turn decreasing download time and archive size. In the rare cases, where a static library is needed and the package maintainer doesn't provide it, the user can either request the inclusion from the maintainer or compile the library his/herself. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux jroger 2.4.19 #1 Don Sep 19 22:32:19 CEST 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] Versions of packages debian-policy depends on: ii coreutils [fileutils] 4.5.1-2The GNU core utilities ii fileutils 4.5.1-2GNU file management utilities -- no debconf information
Bug#168435: debian-policy: Remove the requirement to install static libraries
On Sat, Nov 09, 2002 at 04:25:00PM +0100, Sebastian Rittau wrote: Package: debian-policy Version: 3.5.7.0 Severity: wishlist I suggest the following alteration to the policy: I object strenuously to this proposal. + All libraries must have a shared version in the + ttlib*/tt package and may have a static version in the + ttlib*-dev/tt package. Rationale: The removed paragraph was redundant with the first paragraph of the section and was moved there. You've made it a violation of policy to *not* provided a shared version of a library. Some libraries aren't intended to have shared versions available. For instance, see the package description of xlibs-dev: xlibs-dev provides static versions of the libraries provided in xlibs, as well as several libraries that do not exist in shared object form for various reasons (such as the fact that their APIs have not stabilized, or that they are deprecated). Header files and manual pages are also provided. Also see libtwofish-dev. The main aspect of this proposal is the removed requirement of including static versions of each library in the corresponding -dev package. Many modern libraries don't work well as a static library and usage of static libraries should be deprecated except for a few specific cases. Cite examples. This policy change would allow maintainers to decide for themselves, whether a static version of their library is useful, thereby decreasing the size of many -dev packages and in turn decreasing download time and archive size. In the rare cases, where a static library is needed and the package maintainer doesn't provide it, the user can either request the inclusion from the maintainer or compile the library his/herself. The user can do all kinds of things for hisself [sic]; Debian tries to make such things straightforward. How about a policy proposal that simply clears up the redundancy rather than pursuing a private agenda as a bonus? -- G. Branden Robinson| It just seems to me that you are Debian GNU/Linux | willfully entering an arse-kicking [EMAIL PROTECTED] | contest with a monstrous entity http://people.debian.org/~branden/ | that has sixteen legs and no arse. pgpF86962FvLY.pgp Description: PGP signature
Bug#168435: debian-policy: Remove the requirement to install static libraries
On Sat, Nov 09, 2002 at 05:59:40PM -0500, Branden Robinson wrote: On Sat, Nov 09, 2002 at 04:25:00PM +0100, Sebastian Rittau wrote: + All libraries must have a shared version in the + ttlib*/tt package and may have a static version in the + ttlib*-dev/tt package. Rationale: The removed paragraph was redundant with the first paragraph of the section and was moved there. You've made it a violation of policy to *not* provided a shared version of a library. Some libraries aren't intended to have shared versions available. Agreed. But the current version of the policy already reads: | In general, libraries must have a shared version in the library | package and a static version in the development package. [...] | All libraries must have a shared version in the `lib*' package and a | static version in the `lib*-dev' package. [...] So, it's already a violation not to provide a shared version. (Which is admittedly unreasonable.) This policy change would allow maintainers to decide for themselves, whether a static version of their library is useful, thereby decreasing the size of many -dev packages and in turn decreasing download time and archive size. In the rare cases, where a static library is needed and the package maintainer doesn't provide it, the user can either request the inclusion from the maintainer or compile the library his/herself. The user can do all kinds of things for hisself [sic]; Debian tries to make such things straightforward. s/his/him/ I just don't see the reason why we should waste a lot of bandwidth and storage size just for a hypothetical case. I doubt that there is a significant number of users that will need static version of most of our libraries. Please note that I don't want to remove static versions of libraries from all development packages. I just want to place the inclusion at the maintainer's discretion. How about a policy proposal that simply clears up the redundancy rather than pursuing a private agenda as a bonus? Since this private agenda was why I reviewed the policy section in question, in the first place, I merged these two proposals. If the current proposal fails, I will pursue the redundacy cleanup, at least. - Sebastian
