Bug#555980: debian-policy: No policy on statically linked binaries
On Mon, May 19, 2014 at 10:46:48AM -0700, Jonathan Nieder wrote:
> Hi,
>
> Bill Allombert wrote:
>
> > --- a/policy.sgml
> > +++ b/policy.sgml
> > @@ -8466,7 +8466,11 @@ fi
> > renamed. If a consensus cannot be reached, <em>both</em>
> > programs must be renamed.
> > </p>
> > -
> > + <p>
> > + Binary executables must not be statically linked with the
> > + GNU C library, unless there is technical requirement for
> > + doing so.
> > + </p>
(Please read the original bug log for the full story)
> What does it mean for there to be a technical requirement? For
> example, is there a technical requirement for bash-static to be
> statically linked? (A rescue disk could always include the libc
> shared library instead of using a statically linked binary.)
I would say that a -static package is required to be static.
(though of course the FTP matsers can veto the addition of
such a package).
> xzdec contains binaries statically linked against liblzma but not
> against libc. That means they wouldn't run afoul of this requirement.
> Is that within the spirit of this policy?
I think so.
> What is the purpose of this change?
>
> * avoiding nss pain when libc gets upgraded?
> * license compliance, it being too hard to remember to use
> Built-Using?
> * security, missing out on fixes when libc gets upgraded?
> * something else?
My purpose is for policy to be inline with the FTP masters practice.
For the FTP masters purpose it is a different story, though you are
raising valid points.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: