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. <ballo...@debian.org> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
