Le Sun, Dec 29, 2002 at 03:48:21AM -0600, Adam Heath �crivait: > /usr/share exists for a reason: so it can be shared between systems. Placing > files in /usr/lib is for system-specify(ie, arch-dependant) files, that can > not be shared.
Suppose that we have ModuleXS and ModuleIndep in the same "package". You want me to install ModuleIndep in /usr/share/ and ModuleXS in /usr/lib because we can share /usr/share across various architectures. Fine. Now suppose that ModuleIndep does "use ModuleXS" and that it's useless without ModuleXS, what's the point of sharing ModuleIndep ? You're just taking the risk to make a broken module available to machines that don't have the corresponding binary modules ... on the contrary if ModuleIndep is packaged with the binary module in the same directory, this would never happen. > FHS doesn't classify files by what you do with them. They classify them by > type. And .pm files are sharable. So into /usr/share they go. That's bullshit. We have plenty of files in /usr/lib/ which are not "arch-specific" : check /usr/lib/dpkg/methods/ for example. All files in "/usr/share/" must be shareable. But nothing says that all files in /usr/lib/ must be arch-dependant. We put files in /usr/share/ when the files are shareable and when it makes sense to share them. That's my opinion, I won't argue much more. I think I explained why it makes sense to keep some arch-indep modules in /usr/lib/. I think that the rationale I gave is enough to modify the perl policy accordingly. Now I'll let the policy crew do the rest. :) Cheers, -- Rapha�l Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
