| |||||||||||||
Bitten by the Red Hat Perl bug (InfoWorld)Bitten by the Red Hat Perl bug (InfoWorld)Posted Aug 29, 2008 12:07 UTC (Fri) by jengelh (subscriber, #33263)In reply to: Bitten by the Red Hat Perl bug (InfoWorld) by MattPerry Parent article: Bitten by the Red Hat Perl bug (InfoWorld)
Like 64-bit libraries put into /usr/lib instead of /usr/lib64. Nvidia's manual installer likes to do that sort of crap for example.
Or stuffing things in hilarious locations, like H-Sphere RPMs do.
(Log in to post comments)
Bitten by the Red Hat Perl bug (InfoWorld) Posted Aug 29, 2008 14:57 UTC (Fri) by spot (subscriber, #15640) [Link]
You know, like FHS says to do? Oh wait, I forgot Debian is continuing to pretend that part of the FHS doesn't exist.
http://www.pathname.com/fhs/pub/fhs-2.3.html#LIB64
P.S. It's not optional. It's only optional for that directory to exist on an architecture that doesn't need it.
Bitten by the Red Hat Perl bug (InfoWorld) Posted Aug 29, 2008 17:40 UTC (Fri) by vmole (guest, #111) [Link] Well, let's see: /lib64 and /lib32 : 64/32-bit libraries (architecture dependent) The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in /lib. The 64-bit architecture IA64 must place 64-bit libraries in /lib. It's not even self-consistent: the title says "/lib32" but the text says "/lib". Anyway, the Debian folks are trying to get multiarch implemented so that we have a general long-term solution. In the meantime, the assumption is that Debian is about free software that can be packaged for a specific architecture.
multiarch is vaporware Posted Aug 29, 2008 19:55 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
we are about to hit the second major debian release since multiarch was trotted out as "no, we won't implement things the way everyone else does, we will do this instead", and as far as I can see it's still not fully defined, let alone implemented anywhere. it's not even in the unstable branch, which means that it's extremely unlikly to be in the next stable series after Lenny (which means that it won't matter to most people for several years more)
Bitten by the Red Hat Perl bug (InfoWorld) Posted Aug 31, 2008 23:24 UTC (Sun) by salimma (subscriber, #34460) [Link]
The current multiarch implementation is rather unfortunate. The GNUstep-esque solution is much nicer: have a sub-directory for each architecture under /usr/lib. Do the same for /usr/bin. And while at it, go the full distance and allow for application and framework (library) bundles as well.
The more self-contained applications can be, the less can go wrong with upstream-created packages.
Bitten by the Red Hat Perl bug (InfoWorld) Posted Sep 4, 2008 14:21 UTC (Thu) by pj (subscriber, #4506) [Link]
How 'GNUstep-esque' is Gobolinux?
|
|||||||||||||