On Thu, Nov 14, 2002 at 09:05:58PM +0100, srittau@jroger.in-berlin.de wrote: > I suggest the following alteration to the policy: > +++ policy.sgml 2002-11-09 16:19:08.000000000 +0100 > @@ -5592,12 +5592,12 @@ > <sect> > <heading>Libraries</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 > + <tt>lib*</tt> package and may have a static version in the > + <tt>lib*-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 > - <tt>lib*</tt> package and a static version in the > - <tt>lib*-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. <ballombe@debian.org>
Attachment:
pgp3FHhhMLzlU.pgp
Description: PGP signature