On Thu, Sep 22, 2011 at 05:08:33PM -0500, Jonathan Nieder wrote: > Tollef Fog Heen wrote: > > ]] Steve Langasek > > > | How do we square that with the FHS, then? The FHS says: > > | > > | If directories /lib<qual> or /usr/lib<qual> exist, the equivalent > > | directories must also exist in /usr/local. > > | > > | That seems to require /usr/local/lib64 even if we *don't* include > > | /usr/lib64, right? Should we amend policy to take this exception to the > > | FHS? Please open a bug report on policy if you think we should. > > > > I think this is a bug in the FHS that we need to work around in Debian > > policy. > > libc6 2.13-17 removed the /lib64 and /usr/lib64 symlinks, so the problem > described in bug#612000 no longer exists and there's no reason to want > a /usr/local/lib64 symlink any more. We're left in the less worrisome > situation Steve described, with the question of whether to create a > (useless) /usr/local/lib64 directory. > > So now I can wholeheartedly endorse your proposed change. > > > --- /proc/self/fd/13 2011-02-13 09:12:50.142239544 +0100 > > +++ policy.sgml 2011-02-13 09:12:01.565231567 +0100 > > @@ -5993,6 +5993,13 @@ > > to get access to kernel information.</footnote> > > </p> > > </item> > > + <item> > > + <p> > > + The requirement for > > <file>/usr/local/lib<qual></file> > > + to exist if <file>/lib<qual></file> or > > + <file>/usr/lib<qual></file> exists is removed. > > + </p> > > + </item> > > </enumlist> > > > > </p> > > Seconds?
Seconded. The whole lib64 business was completly backward from the start. Cheers, -- Bill. <ballo...@debian.org> Imagine a large red swirl here.
signature.asc
Description: Digital signature
