In discussing the new Java Guidelines, we've run into the question of whether arch-sepcific but non-multilib packages need to use %{_libdir} for files or if they can be placed in %{_prefix}/lib/ on all arches. Although this is a question brought to the fore by java, it also has bearing on other situations. For instance, this fesco ticket: https://fedorahosted.org/fesco/ticket/969
could also be affected by this question. (as noted by rdieter here: https://fedorahosted.org/fpc/ticket/158#comment:3 )
Although we could grant a special case exception just for java, I think that would be unfair. Making this decision on the more generic level and applying it to java, systemd, and other packages makes more sense to me.
So what are thoughts on allowing both 32bit and 64bit binaries into %{_prefix}/lib if those binaries are not part of a package that will be %multilib'd?
-Tosio
On Wed, Nov 14, 2012 at 10:13:00 -0800, Toshio Kuratomi a.badger@gmail.com wrote:
So what are thoughts on allowing both 32bit and 64bit binaries into %{_prefix}/lib if those binaries are not part of a package that will be %multilib'd?
Sort of related to this is that some systemd related config files are supposed to go into /usr/lib (e.g. modules-load.d) when installed by packages.
Bruno Wolff III (bruno@wolff.to) said:
On Wed, Nov 14, 2012 at 10:13:00 -0800, Toshio Kuratomi a.badger@gmail.com wrote:
So what are thoughts on allowing both 32bit and 64bit binaries into %{_prefix}/lib if those binaries are not part of a package that will be %multilib'd?
Sort of related to this is that some systemd related config files are supposed to go into /usr/lib (e.g. modules-load.d) when installed by packages.
Configuration is a separate case, given that /usr/etc is explicitly FHS-forbidden.
Bill
Toshio Kuratomi wrote:
In discussing the new Java Guidelines, we've run into the question of whether arch-sepcific but non-multilib packages need to use %{_libdir} for files or if they can be placed in %{_prefix}/lib/ on all arches.
...
could also be affected by this question. (as noted by rdieter here: https://fedorahosted.org/fpc/ticket/158#comment:3
...
So what are thoughts on allowing both 32bit and 64bit binaries into %{_prefix}/lib if those binaries are not part of a package that will be %multilib'd?
Personally, the more i think about it, the more it feels right and makes sense to allow this. In essence, one can consider non-multilib'd %_prefix/lib and %_libexecdir content to be equal policy-wise.
-- rex
On Nov 14, 2012 10:36 AM, "Rex Dieter" rdieter@math.unl.edu wrote:
Toshio Kuratomi wrote:
So what are thoughts on allowing both 32bit and 64bit binaries into %{_prefix}/lib if those binaries are not part of a package that will be %multilib'd?
Personally, the more i think about it, the more it feels right and makes sense to allow this. In essence, one can consider non-multilib'd %_prefix/lib and %_libexecdir content to be equal policy-wise.
I've thought of one technical thing that is lost if we allow this but it may not be that important. Currently a sysadmin could install packages on an x86 and then mount the /usr/lib directory on both x86 and x86_64 systems. This is similar to the rationale the FHS uses for splitting /usr/share/ from %{_libdir}. It isn't in the FHS, though, so we aren't required to to keep this feature.
-*Toshio*
On 11/15/2012 09:33 AM, Toshio Kuratomi wrote:
I've thought of one technical thing that is lost if we allow this but it may not be that important. Currently a sysadmin could install packages on an x86 and then mount the /usr/lib directory on both x86 and x86_64 systems.
We already allow folks to use /usr/lib/%{name} and %_libexecdir interchangeably (don't we?), so i'd bet that use-case is already out.
-- rex
On Thu, Nov 15, 2012 at 10:03:30AM -0600, Rex Dieter wrote:
I've thought of one technical thing that is lost if we allow this but it may not be that important. Currently a sysadmin could install packages on an x86 and then mount the /usr/lib directory on both x86 and x86_64 systems.
We already allow folks to use /usr/lib/%{name} and %_libexecdir interchangeably (don't we?),
I think that's the question at hand, actually.
On 11/15/2012 10:20 AM, Matthew Miller wrote:
On Thu, Nov 15, 2012 at 10:03:30AM -0600, Rex Dieter wrote:
I've thought of one technical thing that is lost if we allow this but it may not be that important. Currently a sysadmin could install packages on an x86 and then mount the /usr/lib directory on both x86 and x86_64 systems.
We already allow folks to use /usr/lib/%{name} and %_libexecdir interchangeably (don't we?),
I think that's the question at hand, actually.
See https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#...
not exactly 100% interchangeable ... but already does allow /usr/lib/... in the cases where libexecdir isn't directly supported
-- rex
On 11/15/2012 10:40 AM, Rex Dieter wrote:
On 11/15/2012 10:20 AM, Matthew Miller wrote:
On Thu, Nov 15, 2012 at 10:03:30AM -0600, Rex Dieter wrote:
I've thought of one technical thing that is lost if we allow this but it may not be that important. Currently a sysadmin could install packages on an x86 and then mount the /usr/lib directory on both x86 and x86_64 systems.
We already allow folks to use /usr/lib/%{name} and %_libexecdir interchangeably (don't we?),
I think that's the question at hand, actually.
See https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#...
not exactly 100% interchangeable ... but already does allow /usr/lib/... in the cases where libexecdir isn't directly supported
oh, I totally misread that, *nevermind*. the guideline says %{_libdir}/%{name}
-- rex
On Thu, Nov 15, 2012 at 10:41:40AM -0600, Rex Dieter wrote:
On 11/15/2012 10:40 AM, Rex Dieter wrote:
On 11/15/2012 10:20 AM, Matthew Miller wrote:
On Thu, Nov 15, 2012 at 10:03:30AM -0600, Rex Dieter wrote:
I've thought of one technical thing that is lost if we allow this but it may not be that important. Currently a sysadmin could install packages on an x86 and then mount the /usr/lib directory on both x86 and x86_64 systems.
We already allow folks to use /usr/lib/%{name} and %_libexecdir interchangeably (don't we?),
I think that's the question at hand, actually.
See https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#...
not exactly 100% interchangeable ... but already does allow /usr/lib/... in the cases where libexecdir isn't directly supported
oh, I totally misread that, *nevermind*. the guideline says %{_libdir}/%{name}
Right. And if we decide that this is okay in general we'll probably update that guideline to allow any of %{_libexedir}, %{_libdir}, or %{_prefix}/lib to be used.
-Toshio
On Thu, Nov 15, 2012 at 10:40:28AM -0600, Rex Dieter wrote:
We already allow folks to use /usr/lib/%{name} and %_libexecdir interchangeably (don't we?),
I think that's the question at hand, actually.
See https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#... not exactly 100% interchangeable ... but already does allow /usr/lib/... in the cases where libexecdir isn't directly supported
Nope -- it allows %{_libdir}, which on 64-bit is /usr/lib64. You're not supposed to put 64-bit binaries under /usr/lib/%{name}.
Toshio Kuratomi (a.badger@gmail.com) said:
Personally, the more i think about it, the more it feels right and makes sense to allow this. In essence, one can consider non-multilib'd %_prefix/lib and %_libexecdir content to be equal policy-wise.
I've thought of one technical thing that is lost if we allow this but it may not be that important. Currently a sysadmin could install packages on an x86 and then mount the /usr/lib directory on both x86 and x86_64 systems. This is similar to the rationale the FHS uses for splitting /usr/share/ from %{_libdir}. It isn't in the FHS, though, so we aren't required to to keep this feature.
This implies sharing /usr/lib separate from /usr/libexec, /usr/bin, and so on... I think that's pretty far into the fringe of use cases, and not something we really need to support.
Bill
On 11/14/2012 07:36 PM, Rex Dieter wrote:
Toshio Kuratomi wrote:
In discussing the new Java Guidelines, we've run into the question of whether arch-sepcific but non-multilib packages need to use %{_libdir} for files or if they can be placed in %{_prefix}/lib/ on all arches.
...
could also be affected by this question. (as noted by rdieter here: https://fedorahosted.org/fpc/ticket/158#comment:3
...
So what are thoughts on allowing both 32bit and 64bit binaries into %{_prefix}/lib if those binaries are not part of a package that will be %multilib'd?
Personally, the more i think about it, the more it feels right and makes sense to allow this. In essence, one can consider non-multilib'd %_prefix/lib and %_libexecdir content to be equal policy-wise.
I do not agree. %_libexecdir is policy-wise similar to %_bindir (non multilib'ed).
Ralf
On Mon, Nov 19, 2012 at 06:23:44PM +0100, Ralf Corsepius wrote:
On 11/14/2012 07:36 PM, Rex Dieter wrote:
Personally, the more i think about it, the more it feels right and makes sense to allow this. In essence, one can consider non-multilib'd %_prefix/lib and %_libexecdir content to be equal policy-wise.
I do not agree. %_libexecdir is policy-wise similar to %_bindir (non multilib'ed).
True but -- we already allow %{_libdir}/UNIQUENAME as a standin for %{_libexecdir}/UNIQUENAME even though what goes there is non-multilib'd. So it doesn't seem harmful to allow %{_prefix}/lib as an alternate for the non-multilib'd case as well.
-Toshio
Quoting Toshio Kuratomi (2012-11-14 19:13:00)
Although we could grant a special case exception just for java, I think that would be unfair. Making this decision on the more generic level and applying it to java, systemd, and other packages makes more sense to me.
I know this is not just about Java, but Java is a use case I care about so I'll be frank: Anyone who says we should fully support multilib Java libraries is either ignorant or nuts.
This is not a case of "we don't want to deal with it" or that "we want to be special". This is the case of "we actually have been doing it like this all the way until F14 when *I* tried to make Java stack multilib and it failed". And it failed badly.
Go read [1] where people *actually doing* JNI Java stuff discussed our options. That including OpenJDK developers. We didn't really come up with anything sane in the end. Add our buildsystem that insists that noarch packages cannot reference _libdir and you have a nice basic idea. If you want more information have a look at our proposed draft that's been delayed, which already contains reasons why we simply cannot support multilib[2] in Java.
If you vote to force us to support multilib in Java, I'll either find a way to circumvent that guideline or I'll force each and every one of people voting for it to work on JNI support in 800+ Java packages we have in Fedora. A little warning: my efforts to enable Java multilib in F14 timeframe caused me to cry myself to sleep and *then* having nightmares about all possible scenarios in which things *will* go wrong. It's my biggest regret in my 2.5 years of full time Java packaging.
So what are thoughts on allowing both 32bit and 64bit binaries into %{_prefix}/lib if those binaries are not part of a package that will be %multilib'd?
Uhmm...at least in Java: yeah, good idea!
[1] https://bugzilla.redhat.com/show_bug.cgi?id=665576 [2] https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate#Notes...
On 11/15/2012 03:34 AM, Stanislav Ochotnicky wrote:
I know this is not just about Java, but Java is a use case I care about so I'll be frank: Anyone who says we should fully support multilib Java libraries is either ignorant or nuts.
To be clear too, no one is saying or advocating that. no worries. :)
-- rex
packaging@lists.fedoraproject.org
-
Bill Nottingham -
Bruno Wolff III -
Matthew Miller -
Ralf Corsepius -
Rex Dieter -
Stanislav Ochotnicky -
Toshio Kuratomi