Re: [FHS] helper scripts location
On Mon, 13.06.11 17:41, Miloslav Trmač (m...@volny.cz) wrote:
On Mon, Jun 13, 2011 at 5:36 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
On Mon, 13.06.11 14:27, Matthew Garrett (mj...@srcf.ucam.org) wrote:
It's a directory for arch-dependent stuff that should only exist once on
a system, whereas lib is for arch-dependent stuff that may exist for
multiple architectures on one system. I have no opinion on whether that
distinction is important.
That is not really how it is. /lib is for arch-dependent stuff including
the libraries of the primary arch. Libraries for secondary archs are
then put in /usr/lib{64,arch}/.
On x86_64 the 64-bit arch is primary and the 32-bit arch is secondary.
Surely the 32-bit files don't belong to /usr/lib64?
Mirek
Oh, well, let me clarify this: the executable binaries are actually not
subarch-dependent: i.e. a 32bit process can spawn both 64bit and 32bit
binaries, and a 64bit process can spawn both, too. That means there is
no need to ship both versions of a binary, and while *arch-dependent* an
executable binary is not *subarch-dependent*. That means private
binaries unconditionally belong in /usr/lib, regardless for which
subarch they are compiled and you need only one version of them.
So putting this all together:
/usr/lib is for arch-dependent stuff, including the libraries of the
primary arch, and all subarch-independent private executable
binaries. Libraries for secondary archs (subarchs) are then but in
/usr/lib{64,arch}/.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Mon, 13.06.11 11:52, Simo Sorce (s...@redhat.com) wrote:
On Mon, 2011-06-13 at 17:41 +0200, Miloslav Trmač wrote:
On Mon, Jun 13, 2011 at 5:36 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
On Mon, 13.06.11 14:27, Matthew Garrett (mj...@srcf.ucam.org) wrote:
It's a directory for arch-dependent stuff that should only exist once on
a system, whereas lib is for arch-dependent stuff that may exist for
multiple architectures on one system. I have no opinion on whether that
distinction is important.
That is not really how it is. /lib is for arch-dependent stuff including
the libraries of the primary arch. Libraries for secondary archs are
then put in /usr/lib{64,arch}/.
On x86_64 the 64-bit arch is primary and the 32-bit arch is secondary.
Surely the 32-bit files don't belong to /usr/lib64?
I thinkLennart is saying that on a 64 bit system they would have to go
to /usr/lib32
No, there is no /usr/lib32.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Mon, 13.06.11 13:25, Matthew Miller (mat...@mattdm.org) wrote:
On Mon, Jun 13, 2011 at 05:36:00PM +0200, Lennart Poettering wrote:
That is not really how it is. /lib is for arch-dependent stuff including
the libraries of the primary arch. Libraries for secondary archs are
then put in /usr/lib{64,arch}/.
Gentoo is the only distro which is so confused to put binaries that
belong into /usr/lib into /usr/lib64 just because they are compiled for
64bit. But that's just because they are confused.
Errr, what?
Fedora has the same confusion.
No. For example: on Fedora the udev private binaries are in /lib/udev/
(where they belong). Gentoo is confused and puts them in /lib64/udev/
instead (which is broken).
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Tue, 14.06.11 00:31, Kevin Kofler (kevin.kof...@chello.at) wrote:
Lennart Poettering wrote:
What is the benefit of a separate libexecdir?
The distinction between stuff which belongs into %{_libdir}, which is
different for 32-bit vs. 64-bit, vs. stuff which always goes to the same
place and where only one copy should be installed.
Well, but in which way is arch-dependent non-executable data any
different from private binaries? I see no reason why one should live in
libdir, and the other in libexecdir.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
2011/6/14 Ralf Corsepius rc040...@freenet.de:
On 06/14/2011 12:26 AM, Kevin Kofler wrote:
Haïkel Guémar wrote:
I spent some time yesterday talking with opensuse guys on irc, since
/usr/libexec has not been blessed by FHS
libexecdir is GNU Standards for ages (decades).
It's supposed to be kind of an auxilliary bindir, to hide away
programs, users are not supposed to execute directly.
It's formal definition[1] is
cite
libexecdir
The directory for installing executable programs to be run by other
programs rather than by users. This directory should normally be
‘/usr/local/libexec’, but write it as ‘$(exec_prefix)/libexec’. (If you
are using Autoconf, write it as ‘@libexecdir@’.)
The definition of ‘libexecdir’ is the same for all packages, so you
should install your data in a subdirectory thereof. Most packages
install their data under ‘$(libexecdir)/package-name/’, possibly within
additional subdirectories thereof, such as
‘$(libexecdir)/package-name/machine/version’.
/cite
In Fedora, we treat libexecdir as optional and allow packages to install
such non-user programs to %libdir/subdir/ instead, primarily for
historical reasons.
Actually, libexec can be interpreted as being a libdir with the multilib
suffix exec (just like 64 is one),
Multilib subdirs are arbitrary directory names. There is no convention
of them being named lib*.
You might not have tripped over such them on intel based platforms, but
are very common on other architectures/OSes.
Ralf
[1] http://www.gnu.org/prep/standards/standards.html
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Do we agree that until FHS canonicalize libexecdir, libexecdir is the
recommended location for helper scripts and that /usr/{lib,share} are
*tolerated* (ie: not configurable, requires non-upstream-able
intrusive patch etc ...) ? In consequence, we should then update
packaging guidelines to explicitely state this.
http://bugs.linuxfoundation.org/show_bug.cgi?id=101
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On 06/14/2011 11:57 AM, 80 wrote:
2011/6/14 Ralf Corsepiusrc040...@freenet.de:
On 06/14/2011 12:26 AM, Kevin Kofler wrote:
Haïkel Guémar wrote:
I spent some time yesterday talking with opensuse guys on irc, since
/usr/libexec has not been blessed by FHS
libexecdir is GNU Standards for ages (decades).
It's supposed to be kind of an auxilliary bindir, to hide away
programs, users are not supposed to execute directly.
It's formal definition[1] is
cite
libexecdir
The directory for installing executable programs to be run by other
programs rather than by users. This directory should normally be
‘/usr/local/libexec’, but write it as ‘$(exec_prefix)/libexec’. (If you
are using Autoconf, write it as ‘@libexecdir@’.)
The definition of ‘libexecdir’ is the same for all packages, so you
should install your data in a subdirectory thereof. Most packages
install their data under ‘$(libexecdir)/package-name/’, possibly within
additional subdirectories thereof, such as
‘$(libexecdir)/package-name/machine/version’.
/cite
In Fedora, we treat libexecdir as optional and allow packages to install
such non-user programs to %libdir/subdir/ instead, primarily for
historical reasons.
[1] http://www.gnu.org/prep/standards/standards.html
Do we agree that until FHS canonicalize libexecdir, libexecdir is the
recommended location for helper scripts and that /usr/{lib,share} are
*tolerated* (ie: not configurable, requires non-upstream-able
intrusive patch etc ...) ?
Well, I would agree to tolerating /usr/lib/package/ (Which btw is the
current defacto rule in Fedora practice) but would disagree otherwise,
because
- /usr/share (aka datadir) is reserved for arch-independent data, i.e.
should not contain executables and programs.
- /usr/lib (according to the GNU coding standards) should not contain
programs.
- $(libdir)/package/ basically is a package's private play-ground and
therefore may also contain programs and scripts.
In consequence, we should then update
packaging guidelines to explicitely state this.
sigh/ some people seem to need written rules for everything, for what
generations of people before them took for granted ;)
Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
2011/6/14 Ralf Corsepius rc040...@freenet.de: Well, I would agree to tolerating /usr/lib/package/ (Which btw is the current defacto rule in Fedora practice) but would disagree otherwise, because - /usr/share (aka datadir) is reserved for arch-independent data, i.e. should not contain executables and programs. - /usr/lib (according to the GNU coding standards) should not contain programs. - $(libdir)/package/ basically is a package's private play-ground and therefore may also contain programs and scripts. ok. sigh/ some people seem to need written rules for everything, for what generations of people before them took for granted ;) Ralf We should at least document exceptions to best practices so we can confine them in a small corner. :) Dark corners are basically fractal — no matter how much you illuminate, there's always a smaller but darker one. - Brian Kernighan (one third of the holy *nixy trinity) H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
Ralf Corsepius wrote: Multilib subdirs are arbitrary directory names. There is no convention of them being named lib*. There is, it's written in the FHS: http://www.pathname.com/fhs/pub/fhs-2.3.html#LIBLTQUALGTALTERNATEFORMATESSENTIAL But I don't see anything banning qual=exec there! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
Ralf Corsepius wrote: Multilib subdirs are arbitrary directory names. There is no convention of them being named lib*. PS: Actually this: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLTQUALGTALTERNATEFORMATLIBRARI is the relevant reference for /usr/libqual (the other one was for /libqual). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
Lennart Poettering wrote: Well, but in which way is arch-dependent non-executable data any different from private binaries? I see no reason why one should live in libdir, and the other in libexecdir. Arch-dependent libraries need to be multilib (both in lib and lib64), for executables, only one copy is needed. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On 06/14/2011 04:02 PM, Kevin Kofler wrote: Ralf Corsepius wrote: Multilib subdirs are arbitrary directory names. There is no convention of them being named lib*. There is, it's written in the FHS: http://www.pathname.com/fhs/pub/fhs-2.3.html#LIBLTQUALGTALTERNATEFORMATESSENTIAL This has nothing to do with multilibs. FWIW: On most non-intel/non-linux targets, all multilibs are below /usr/lib and are not prefixed with lib*. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
Lennart Poettering (mzerq...@0pointer.de) said: I thinkLennart is saying that on a 64 bit system they would have to go to /usr/lib32 No, there is no /usr/lib32. Correct. /usr/lib is 32-bit libraries, /usr/lib64 is 64-bit libraries. (*) My objection to putting 64-bit helper binaries in /usr/lib/app would merely be the problems with configuration that that may imply; such a change may not be transparent to packages. Bill (*) We are ignoring Itanium and Alpha for this conversation, because, well... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Mon, Jun 13, 2011 at 02:18:18PM +0200, Lennart Poettering wrote:
What is the benefit of a separate libexecdir?
I guess because binaries shouldn't go in the library directory.
Now if you wanted to get rid of the {,/usr}/lib64 nonsense, *that*'s
something we can all get behind ...
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Mon, 2011-06-13 at 13:41 +0100, Richard W.M. Jones wrote:
On Mon, Jun 13, 2011 at 02:18:18PM +0200, Lennart Poettering wrote:
What is the benefit of a separate libexecdir?
I guess because binaries shouldn't go in the library directory.
Now if you wanted to get rid of the {,/usr}/lib64 nonsense, *that*'s
something we can all get behind ...
How would you handle multilib and how would you transition stuff ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Mon, Jun 13, 2011 at 02:27:55PM +0100, Matthew Garrett wrote: On Mon, Jun 13, 2011 at 03:16:45PM +0200, Lennart Poettering wrote: On Mon, 13.06.11 13:41, Richard W.M. Jones (rjo...@redhat.com) wrote: On Mon, Jun 13, 2011 at 02:18:18PM +0200, Lennart Poettering wrote: What is the benefit of a separate libexecdir? I guess because binaries shouldn't go in the library directory. But it isn't a library directory. It's a directory for arch-depndendant stuff, which includes (but is not limited to) libraries. It's a directory for arch-dependent stuff that should only exist once on a system, whereas lib is for arch-dependent stuff that may exist for multiple architectures on one system. I have no opinion on whether that distinction is important. nod See the thread I linked to previously for people working out the nuances and reasons behind that. -Toshio pgpcsGOz4p2gB.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Mon, 13.06.11 14:27, Matthew Garrett (mj...@srcf.ucam.org) wrote:
On Mon, Jun 13, 2011 at 02:18:18PM +0200, Lennart Poettering wrote:
What is the benefit of a separate libexecdir?
I guess because binaries shouldn't go in the library directory.
But it isn't a library directory. It's a directory for arch-depndendant
stuff, which includes (but is not limited to) libraries.
It's a directory for arch-dependent stuff that should only exist once on
a system, whereas lib is for arch-dependent stuff that may exist for
multiple architectures on one system. I have no opinion on whether that
distinction is important.
That is not really how it is. /lib is for arch-dependent stuff including
the libraries of the primary arch. Libraries for secondary archs are
then put in /usr/lib{64,arch}/.
Gentoo is the only distro which is so confused to put binaries that
belong into /usr/lib into /usr/lib64 just because they are compiled for
64bit. But that's just because they are confused.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Mon, 2011-06-13 at 17:41 +0200, Miloslav Trmač wrote:
On Mon, Jun 13, 2011 at 5:36 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
On Mon, 13.06.11 14:27, Matthew Garrett (mj...@srcf.ucam.org) wrote:
It's a directory for arch-dependent stuff that should only exist once on
a system, whereas lib is for arch-dependent stuff that may exist for
multiple architectures on one system. I have no opinion on whether that
distinction is important.
That is not really how it is. /lib is for arch-dependent stuff including
the libraries of the primary arch. Libraries for secondary archs are
then put in /usr/lib{64,arch}/.
On x86_64 the 64-bit arch is primary and the 32-bit arch is secondary.
Surely the 32-bit files don't belong to /usr/lib64?
I thinkLennart is saying that on a 64 bit system they would have to go
to /usr/lib32
But this is wasteful, it means that:
A) You cannot use the same packages on a 32bit system and a 64bit
system. You have to compile additional 32bit packages for installation
on 64bit systems, or do some fancy relocation within rpm.
B) you cannot easily convert a system from 32 - 64 bit as you would
have to move everything around.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Mon, Jun 13, 2011 at 05:36:00PM +0200, Lennart Poettering wrote:
That is not really how it is. /lib is for arch-dependent stuff including
the libraries of the primary arch. Libraries for secondary archs are
then put in /usr/lib{64,arch}/.
Gentoo is the only distro which is so confused to put binaries that
belong into /usr/lib into /usr/lib64 just because they are compiled for
64bit. But that's just because they are confused.
Errr, what?
Fedora has the same confusion.
--
Matthew Miller mat...@mattdm.org
Senior Systems Architect -- Instructional Research Computing Services
Harvard School of Engineering Applied Sciences
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Mon, Jun 13, 2011 at 08:43:46AM -0400, Simo Sorce wrote:
On Mon, 2011-06-13 at 13:41 +0100, Richard W.M. Jones wrote:
On Mon, Jun 13, 2011 at 02:18:18PM +0200, Lennart Poettering wrote:
What is the benefit of a separate libexecdir?
I guess because binaries shouldn't go in the library directory.
Now if you wanted to get rid of the {,/usr}/lib64 nonsense, *that*'s
something we can all get behind ...
How would you handle multilib and how would you transition stuff ?
Shooting multilib in the head and just using 64 bit everywhere?
The only reason to have support for 32 bit is because of closed source
software, and I don't have any of that on all but two of my (dozens of)
machines.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Mon, Jun 13, 2011 at 07:57:46PM +0200, drago01 wrote:
On Mon, Jun 13, 2011 at 7:44 PM, Richard W.M. Jones rjo...@redhat.com wrote:
On Mon, Jun 13, 2011 at 08:43:46AM -0400, Simo Sorce wrote:
On Mon, 2011-06-13 at 13:41 +0100, Richard W.M. Jones wrote:
On Mon, Jun 13, 2011 at 02:18:18PM +0200, Lennart Poettering wrote:
What is the benefit of a separate libexecdir?
I guess because binaries shouldn't go in the library directory.
Now if you wanted to get rid of the {,/usr}/lib64 nonsense, *that*'s
something we can all get behind ...
How would you handle multilib and how would you transition stuff ?
Shooting multilib in the head and just using 64 bit everywhere?
You only getting 32bit libs / apps when you install them so no reason
to get rid of them and make life harder for those who need them.
Obviously I was being deliberately provocative by my original
statement.
Nevertheless, multilib is a broken hack which imposes a burden on me
as a packager, even though I rarely if ever enjoy the fruits of it. I
still have to deal with multilib packaging bugs as they come up.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
mån 2011-06-13 klockan 11:52 -0400 skrev Simo Sorce:
On Mon, 2011-06-13 at 17:41 +0200, Miloslav Trmač wrote:
On Mon, Jun 13, 2011 at 5:36 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
That is not really how it is. /lib is for arch-dependent stuff including
the libraries of the primary arch. Libraries for secondary archs are
then put in /usr/lib{64,arch}/.
On x86_64 the 64-bit arch is primary and the 32-bit arch is secondary.
Surely the 32-bit files don't belong to /usr/lib64?
Don't think of it as primary and secondary. Think of it as the arch
that got its hands on /usr/lib first and the arch that had to make do
with another directory for its conflicting files.
I thinkLennart is saying that on a 64 bit system they would have to go
to /usr/lib32
I don't think that's what Lennart means...
The difference between libraries and binaries is that with libraries you
sometimes need both the primary and the secondary, but with binaries you
only need one, so those binaries can go in the same directory /usr/lib
regardless of their arch. (Just like there's no bin64.)
To put it another way:
Sure, /usr/libexec could be removed, but there's no need to then split
its content into /usr/lib and /usr/lib64. Only use lib64 in the cases
where there would be a conflict between the two arches.
/abo
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
Lennart Poettering wrote:
What is the benefit of a separate libexecdir?
The distinction between stuff which belongs into %{_libdir}, which is
different for 32-bit vs. 64-bit, vs. stuff which always goes to the same
place and where only one copy should be installed.
Now it's possible to hardcode /usr/lib (and some stuff notoriously does
this), but IMHO this is all broken. Everything installed by an x86_64 RPM
into /usr/lib is in the wrong place. It should be in /usr/libexec,
/usr/share, /usr/bin or /usr/lib64.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On 06/14/2011 12:26 AM, Kevin Kofler wrote: Haïkel Guémar wrote: I spent some time yesterday talking with opensuse guys on irc, since /usr/libexec has not been blessed by FHS libexecdir is GNU Standards for ages (decades). It's supposed to be kind of an auxilliary bindir, to hide away programs, users are not supposed to execute directly. It's formal definition[1] is cite libexecdir The directory for installing executable programs to be run by other programs rather than by users. This directory should normally be ‘/usr/local/libexec’, but write it as ‘$(exec_prefix)/libexec’. (If you are using Autoconf, write it as ‘@libexecdir@’.) The definition of ‘libexecdir’ is the same for all packages, so you should install your data in a subdirectory thereof. Most packages install their data under ‘$(libexecdir)/package-name/’, possibly within additional subdirectories thereof, such as ‘$(libexecdir)/package-name/machine/version’. /cite In Fedora, we treat libexecdir as optional and allow packages to install such non-user programs to %libdir/subdir/ instead, primarily for historical reasons. Actually, libexec can be interpreted as being a libdir with the multilib suffix exec (just like 64 is one), Multilib subdirs are arbitrary directory names. There is no convention of them being named lib*. You might not have tripped over such them on intel based platforms, but are very common on other architectures/OSes. Ralf [1] http://www.gnu.org/prep/standards/standards.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Thu, Jun 09, 2011 at 12:14:45PM +0200, 80 wrote: Hi, I'm reviewing osc and osc-source_validators (osc is Opensuse Build Service CLI, the latter a plugin to the former). An issue arose about helpers script location: 1) Fedora packaging guidelines suggests helpers *should go* /usr/libexec for helpers == requires patching since osc search helpers in /usr/lib since it's not in FHS, it's almost certain that a patch won't be upstream-able This would be the most proper location on Fedora. Note that many upstreams do take patches of this sort as long as the libexecdir is settable. libexecdir is a GNU Coding Standard directory; on Debian or other systems that disallow /usr/libexecdir, libexecdir gets set to /usr/lib. http://www.gnu.org/prep/standards/html_node/Directory-Variables.html 2) FHS explicitely allows shell scripts in /usr/lib I don't actually see this. Could you point me to the quote and section? Additionally, the GNU Coding standards explicitly prohibit this (to be clear the GNU coding standards are not definitive for Fedora like the FHS is at this time; I'm including the quotation to show what current best practices are in this regard): ‘libdir’ The directory for object files and libraries of object code. Do not install executables here, they probably ought to go in ‘$(libexecdir)’ instead. At similar weight is the fact that some programs currently violate the GNU Coding Standard recommendation here. However, I can't think of one of those off the top of my head that is a unix-y program so those may be more workaround than paradigm setters. 3) FHS doesn't forbid putting them in /usr/share as helpers could be considered as arch independent data nod There are recent packages that choose options 2 3 (namely, systemd and dracut). According to me, guidelines doesn't enforce any of these options, and choice is left to packager/reviewer appreciation, though you may distinguish an order of precedence. So, what's the take of my fellow packagers on that particular matter ? Preference-wise, I would say $LIBEXECDIR; settable at build time to /usr/libexec on Fedora-style distros and /usr/lib on Debian-style distros is the best method here. Since we're talking scripts (architecture independent), /usr/share may also make sense but I'm not a big fan of it. If you can find me the piece of FHS that explicitly allows shell scripts in /usr/lib I can figure out how that compares to using /usr/lib. -Toshio pgpJOiL9MbpJG.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
Le 10/06/2011 18:56, Toshio Kuratomi a écrit : I don't actually see this. Could you point me to the quote and section? /usr/libincludes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts. http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA Additionally, the GNU Coding standards explicitly prohibit this (to be clear the GNU coding standards are not definitive for Fedora like the FHS is at this time; I'm including the quotation to show what current best practices are in this regard): ‘libdir’ The directory for object files and libraries of object code. Do not install executables here, they probably ought to go in ‘$(libexecdir)’ instead. At similar weight is the fact that some programs currently violate the GNU Coding Standard recommendation here. However, I can't think of one of those off the top of my head that is a unix-y program so those may be more workaround than paradigm setters. good to know Preference-wise, I would say $LIBEXECDIR; settable at build time to /usr/libexec on Fedora-style distros and /usr/lib on Debian-style distros is the best method here. Since we're talking scripts (architecture independent), /usr/share may also make sense but I'm not a big fan of it. If you can find me the piece of FHS that explicitly allows shell scripts in /usr/lib I can figure out how that compares to using /usr/lib. -Toshio +1 I spent some time yesterday talking with opensuse guys on irc, since /usr/libexec has not been blessed by FHS, they won't move helpers from /usr/lib which is FHS-compliant location. I think that packaging guidelines should clarify this point, either we enforce the use of /usr/libexec (and current packages should be fixed) or we explicitely allow /usr/lib and/or /usr/share for helpers. Personnally, i don't feel like burdening the reviewee with a non-FHS compliant patch that has little chance to be upstreamed if it's not mandatory. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
Le vendredi 10 juin 2011 à 21:23 +0200, Haïkel Guémar a écrit : I spent some time yesterday talking with opensuse guys on irc, since /usr/libexec has not been blessed by FHS, they won't move helpers from /usr/lib which is FHS-compliant location. I think that packaging guidelines should clarify this point, either we enforce the use of /usr/libexec (and current packages should be fixed) or we explicitely allow /usr/lib and/or /usr/share for helpers. Or better, since the FHS process has been re-started, people that feel strongly about something not covered by the current FHS version should just make the effort to push the changes they want in the next FHS revision. This way everyone else can just continue to require strict FHS compliance and not bother with special not-really-documented exceptions -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
On Fri, Jun 10, 2011 at 09:23:54PM +0200, Haïkel Guémar wrote:
Le 10/06/2011 18:56, Toshio Kuratomi a écrit :
I don't actually see this. Could you point me to the quote and section?
/usr/libincludes object files, libraries, and internal binaries that
are not intended to be executed directly by users or shell scripts.
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA
Ah -- in your original mesage you said that FHS explicitly blessed /usr/lib
as a place for shell scripts... which is not what this is saying. However,
the description of internal binaries might fit the bill -- the FHS (and
Fedora's usage) of binaries is not always consistent. Sometimes it is
equivalent to object files and other times it is equivalent to
executables. If we interpret this as executable then I think it works.
Note that this portion of the FHS is in direct conflict with the GNU Coding
standards which explicitly says not to use libdir in this way :-(
Additionally, the GNU Coding standards explicitly prohibit this (to be clear
the GNU coding standards are not definitive for Fedora like the FHS is at
this time; I'm including the quotation to show what current best practices
are in this regard):
‘libdir’
The directory for object files and libraries of object code. Do not install
executables here, they probably ought to go in ‘$(libexecdir)’ instead.
At similar weight is the fact that some programs currently violate the GNU
Coding Standard recommendation here. However, I can't think of one of those
off the top of my head that is a unix-y program so those may be more
workaround than paradigm setters.
good to know
Preference-wise, I would say $LIBEXECDIR; settable at build time to
/usr/libexec on Fedora-style distros and /usr/lib on Debian-style distros is
the best method here. Since we're talking scripts (architecture
independent), /usr/share may also make sense but I'm not a big fan of it.
If you can find me the piece of FHS that explicitly allows shell scripts in
/usr/lib I can figure out how that compares to using /usr/lib.
-Toshio
+1
I spent some time yesterday talking with opensuse guys on irc, since
/usr/libexec has not been blessed by FHS, they won't move helpers from
/usr/lib which is FHS-compliant location.
Is this stuff a GNU configure compiled program? Or does it have
a different build system? (You could point me at the tarball/review request
and I could take a look).
I think that packaging guidelines should clarify this point, either we
enforce the use of /usr/libexec (and current packages should be fixed)
or we explicitely allow /usr/lib and/or /usr/share for helpers.
Personnally, i don't feel like burdening the reviewee with a non-FHS
compliant patch that has little chance to be upstreamed if it's not
mandatory.
I just reread the thread where we discussed the pros and cons of libexecdir
and here's the take aways for when and why to use libexecdir:
http://thread.gmane.org/gmane.linux.redhat.fedora.devel/25433/
1) Determine if the program cares about the wordsize of the helpers.
* Are the helper programs mandatorily architecture independent or could
they be arch dependent (ex: It's only convenient to write them in shell,
the helpers could be written in C and compiled instead).
* If it's only convenience, how likely is it that helpers would be written
in a compiled language? Would upstream consider it a bug if someone
wrote a helper in a compiled language?
2.a) If the program does not care about the wordsize, then options are
libexecdir or datadir.
* Of the two, libexecdir is mandatory if architecture-specific helpers are
allowed.
* libexecdir is likely better even if architecture-specific helpers are
not allowed as datadir is for data files and executable code is
something of a stretch to classify that way.
* Finally, see the last bullet of 2.b) for what the ramifications of using
%{_libdir} are and whether that's acceptable in this specific case.
2.b) If the program does care about wordsize, then you need to use %_libdir
which will either be /usr/lib or /usr/lib64 on Fedora. The application
(or config file) will need to be compiled/configured to know which path
to use based on compilation (note that this may require a patch to
upstream as well).
* If the program does not care about wordsize but you put it into
%{_libdir} anyway, you force helpers in separate packages/subpackages to
be packaged arch-specific even though the only difference is the path
pointed to by %{_libdir}. This is a pain but it's something that can
be survived as long as people realize that they have to do this. It
doesn't have as significant an impact if all of the helpers are in the
original package; helpers don't get added to by separate packages.
-Toshio
pgpejX83B5g0z.pgp
Description: PGP signature
--
devel mailing list
[FHS] helper scripts location
Hi, I'm reviewing osc and osc-source_validators (osc is Opensuse Build Service CLI, the latter a plugin to the former). An issue arose about helpers script location: 1) Fedora packaging guidelines suggests helpers *should go* /usr/libexec for helpers == requires patching since osc search helpers in /usr/lib since it's not in FHS, it's almost certain that a patch won't be upstream-able 2) FHS explicitely allows shell scripts in /usr/lib 3) FHS doesn't forbid putting them in /usr/share as helpers could be considered as arch independent data There are recent packages that choose options 2 3 (namely, systemd and dracut). According to me, guidelines doesn't enforce any of these options, and choice is left to packager/reviewer appreciation, though you may distinguish an order of precedence. So, what's the take of my fellow packagers on that particular matter ? Best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
