Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
Matthew Garrett wrote: Unit files need to be in /, so moving them would either require creating a /share for distributions that haven't merged /usr or putting up with inconsistent naming between distributions. Consistency is a virtue and the chances of getting anyone else to accept /share are minimal, so /lib it is. Meanwhile, libexec's not part of any non-draft version of the FHS and doesn't exist on most other distributions, and the path of the helper binaries has ended up in a bunch of unit files. So, similar problems. What benefit do you see in modifying systemd? Consistency WITHIN FEDORA, which should be worlds more important than consistency with other distros, which frankly I don't give a darn about. As for libexec, the FHS explicitly allows lib* under the multilib clause and there's nothing banning * = exec there, so IMHO libexec is already compliant to the letter of the FHS. If the other distros refuse to accept that, that's their problem. Systemd should just require it upstream. libexec is also part of the GNU file system conventions, so it wouldn't just be systemd. If systemd upstream refuses to do that, the systemd maintainers should be forced to change it in Fedora. And a /share also makes a lot of sense for distros which have a separate /usr. There too, systemd should just require it upstream, but again, if they refuse to do that, they should be forced to change it in Fedora. Being strict there might actually end up getting our sane layout enforced through systemd upstream, rather than having it diluted in the name of consistency with other distros. And if it doesn't, it's too bad for the other distros, why should we care? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
Miloslav Trmač wrote: The exceptions were granted to avoid the impact of fixing this on developers, and more importantly on users (the /usr/lib/systemd paths for units are in various documentation, and even worse the paths to binaries in /usr/lib/systemd are embedded in users' copies of units placed in /etc/; moving the binaries would break users' configuration). Guess what, the documentation needs to be updated. Systemd as is does not conform to any sane file system structure. This MUST be fixed, even if it means breaking compatibility. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On 12/21/2012 12:27 AM, Matthew Garrett wrote: On Thu, Dec 20, 2012 at 10:30:37PM +, Richard W.M. Jones wrote: Thanks, but I think the bit I'm mising is why can't systemd use libexec? (Apart from their declaration that libexec is wrong or not the de-facto standard they themselves made up, which is not a reason). Because libexec doesn't exist on most other distributions, and systemd aims to offer consistent interfaces across distributions. Shouldn't binaries which are part of the external interface reside in /usr/sbin? If the paths are not part of the interface, cross-distribution consistency shouldn't matter (as seen with git, for example). -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On 12/21/2012 09:24 AM, Florian Weimer wrote: On 12/21/2012 12:27 AM, Matthew Garrett wrote: On Thu, Dec 20, 2012 at 10:30:37PM +, Richard W.M. Jones wrote: Thanks, but I think the bit I'm mising is why can't systemd use libexec? (Apart from their declaration that libexec is wrong or not the de-facto standard they themselves made up, which is not a reason). Because libexec doesn't exist on most other distributions, and systemd aims to offer consistent interfaces across distributions. Shouldn't binaries which are part of the external interface reside in /usr/sbin? No. /usr/sbin was used for sys-admin binaries, which were not required during bootup and not useful to ordinary users. Since Fedora has fallen into the UsrMove-trap, this argument is moot on Fedora. If the paths are not part of the interface, cross-distribution consistency shouldn't matter (as seen with git, for example). Correct. That's what the GCS are recommending libexecdir is for. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 07:45:45AM +, Matthew Garrett wrote: On Thu, Dec 20, 2012 at 11:24:09PM -0800, Toshio Kuratomi wrote: 2) the systemd exceptions allows placing files in %{_prefix}/lib rather than %{_libdir} (the exceptions allow both putting the helper apps in there which would generally be okay with just a multilib exception and the unit files which are arch specific data and therefore usually go in %{_libdir} and therefore needed a special exception). The only reason people can drag %{_libexecdir} in to this discussion is that helper binaries are allowed in either %{_libdir} or %{_libexecdir}. In the context of forcing people to use a specific directory not specified by standards its meaningless because %{_libdir} is a suitable alternative. I think the libexec discussion is fairly relevant. Right now a package can drop binaries in libexecdir and have a consistent path regardless of the architecture, which is valuable. However, doing so results in inconsistencies with other distributions which don't provide libexecdir. This is clearly suboptimal, and it's reasonable to ask that the packaging guidelines recognise that and handle it without requiring additional exceptions - if a package wouldn't require an exception to install binaries in libexec, it shouldn't need an exception install binaries in lib. I think the FPC has gotten pretty close to that. I reopened discussion in the FPC ticket about this because we recently approved packages which were exmpt from multilib from having to choose %{_libdir} over %{_prefix}/lib.for things like helper binaries (the guideline was brought up because of java but we passed a generic guideline update that can include helper binaries as well). However, people were concerned that packagers wouldn't necessarily judge correctly whether their packages were truly deserving to be exempt from multilib so the packages needed to be confirmed to be exempt from multilib requirements first. I've been calling that a multilib exception but perhaps multilib exemption would be clearer. It's not about this being an exceptional or special case. It's a case where if you fit certain criteria then you are exempt from certain restrictions. I have been unable to think of any reason that the types of binaries that belong in libexec would fail to be exempted from the considerations of multilib so I think we're in agreement about what the expected outcome should be for those types of files. However, you also miss my point. Adam's message was saying that the guidelines forced people to use libexecdir and then went on to point out the drawbacks of forcing specifically libexecdir on upstreams that didn't have that coded in. So, as I said, in that context it's meaningless to bring up arguments that are only addressed to libexecdir because %{_libdir} is an alternative. -Toshio pgplwCmVbWU3A.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, Dec 20, 2012 at 11:39:53PM -0800, Adam Williamson wrote: I do apologize for somewhat derailing things towards the libexecdir discussion, though, as I missed the point about the real question here being between /lib/foo and $libdir/foo . The libexecdir thing is kind of a tangent and probably should be split out if we're going to keep talking about it. I disagree with some of the assertions you made in this reply but I feel no need to Rooster Cogburn you so I'm willing to agree that it's a tangent :-) -Toshio pgpkZ9jkx0yb1.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On 12/21/2012 09:42 AM, Toshio Kuratomi wrote: On Fri, Dec 21, 2012 at 07:45:45AM +, Matthew Garrett wrote: On Thu, Dec 20, 2012 at 11:24:09PM -0800, Toshio Kuratomi wrote: However, you also miss my point. Adam's message was saying that the guidelines forced people to use libexecdir and then went on to point out the drawbacks of forcing specifically libexecdir on upstreams that didn't have that coded in. Again, many packages have the basic means to implement it built-in (all those using autoconf). However, * packages having been developed on non-multilib'ed systems (most packages with a Debian/Ubuntu origin) often are not taking advantage of libexecdir, because its implementors are not aware about the problems installing into %{_libdir} causes. * in many cases, adding libexecdir support is trivial (no idea about systemd) So, as I said, in that context it's meaningless to bring up arguments that are only addressed to libexecdir because %{_libdir} is an alternative. I do not agree with your conclusion. Enforcing %{_libexecdir} is one possible approach to gradually resolve the issues we are discussing here, in many situations. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, 21.12.12 05:06, Matthew Garrett (mj...@srcf.ucam.org) wrote: On Thu, Dec 20, 2012 at 08:57:58PM -0700, Kevin Fenzi wrote: IMHO, libexecdir is not part of this at all... we already have: If upstream's build scripts support the use of %{_libexecdir} then that is the most appropriate place to configure it (eg. passing --libexecdir=%{libexecdir}/%{name} to autotools configure). If upstream's build scripts do not support that, %{_libdir}/%{name} is a valid second choice. It's all about the choice of lib instead of %{_libdir}. The problem is that in the absence of libexec, there's no consistent location to put helper binaries. %{_libdir}/%{name} doesn't work - depending on distribution and architecture, your files are now either in lib/name, lib32/name or lib64/name. Far from ideal. Lennart's position that fundamental system infrastructure belongs in lib makes sense, since there's absolutely no good reason for multilibing those components. Yes, absolutely. That's key here: multilibbing things should be the exception, and used where strictly *necessary*, not the default for all files. That means that libraries should go to %{_libdir} since they need to be available for both 32bit and 64bit. However, non-library stuff such as internal binaries, or anything else arch specific should not be in %{_libdir}, but in lib/. Multilib is not pretty, it's primarily just a hack to fix one specific problem, and one shouldn't let this specific spill in an otherwise fine design. Hence: use multilib if you must for a specific file, but only then. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, 20.12.12 18:48, Toshio Kuratomi (a.bad...@gmail.com) wrote: Ahem. Isn't your own first sentence suggesting that *your* way is the one and only right way? I don't see how you can attack Lennart for having a firm belief about what's the 'right way' when you also seem to have a firm belief about what's the 'right way'... The FPC Guidelines give package maintainers the option of using %{_libexecdir}, %{_libdir}. The recent changes that I worked on allow %{_prefix}/lib in certain cases. When FPC at large decided that portions of what systemd wanted to do still didn't completely fall under those cases, I took the request from FPC that FESCo simply grant a special exception for systemd to FESCo. So if you're arguing that my firm belief is also a right way or the highway, belief then you aren't arguing about the use of lib, libexec, and lib64 anymore. You're opening up a much larger conversation about whether top-down or bottom-up decision making is the direction that Fedora should be taking in the future; whether Fedora management should decide on one and only one way to do things and then force every packager to do things that way. But if you want to go that route on this question, then it should be noted that FPC ruled that the use that systemd makes of %{_prefix}/lib was wrong under the prior guidelines but the systemd maintainers refused to make their package conform. So while you might pose that question it's not likely to have a more desirable outcome for the systemd package maintainers than what they have now. BTW, I am fine with giving packages a certain amount of freedom how they want to handle things, but I also believe that guidelines should *guide*, i.e. suggest a a way to go, and I believe that suggested way to go is lib/package rather than %{_libexecdir}. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, 21.12.12 05:38, Ralf Corsepius (rc040...@freenet.de) wrote: On 12/21/2012 12:27 AM, Matthew Garrett wrote: On Thu, Dec 20, 2012 at 10:30:37PM +, Richard W.M. Jones wrote: Thanks, but I think the bit I'm mising is why can't systemd use libexec? (Apart from their declaration that libexec is wrong or not the de-facto standard they themselves made up, which is not a reason). Because libexec doesn't exist on most other distributions, libexecdir is part of the GNU standards for ages. The GNU standard is kinda flawed and nobody uses that as 1:1. I mean, /usr/etc? /usr/var?? /us/com??? It's probably more interesting in looking at the more realistic standards, such as FHS, and on what is actually really implemented, rather than on GNU which is really mostly theory... I mean, not even Debian as the distro closest to GNU follows much of that... I disagree. systemd simply hasn't taken libexecdir into account in its design and now is trying to propagate their oversight/mistake as standard instead of making their works compliant with _our_ distro's demands. No, we just look around, and try to do something that is not specific to a distro, somewhat sane and follows the schemes of the established to the level where they make sense. I mean, we really wanted to avoid that unit files end up in different dirs on various distros. No distro but Fedora uses libdexecdir, hence we didn't put suff in there. And /share doesn't exist in the root dir, hence all distros which haven't merge /usr can't have the unit files in /share, hence /lib is the only option. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, 21.12.12 07:01, Ralf Corsepius (rc040...@freenet.de) wrote: On 12/21/2012 06:16 AM, Adam Williamson wrote: On Fri, 2012-12-21 at 06:09 +0100, Ralf Corsepius wrote: On 12/21/2012 05:54 AM, Matthew Garrett wrote: On Fri, Dec 21, 2012 at 05:38:17AM +0100, Ralf Corsepius wrote: I disagree. systemd simply hasn't taken libexecdir into account in its design and now is trying to propagate their oversight/mistake as standard instead of making their works compliant with _our_ distro's demands. libexec doesn't exist in any published version of the FHS, FHS != GCS http://www.gnu.org/prep/standards/standards.html#Directory-Variables IIRC, it's around there for at approx 20 years. I've never seen any distro take any notice of this standard whatsoever. Bummer ... you have been living in a vacuum for the last 20 years and have never been coding any a little more complex package ? RPM respects the GCS ever since RPM exists, autoconf honors it ever since autoconf and the GCS exists and all major GNU and many more projects honor it. That's simply not true: https://www.gnu.org/prep/standards/html_node/Directory-Variables.html GNU suggests sharedstatedir=$(prefix)/com, localstatedir=$(prefix)/var, sysconfdir=$(prefix)/etc, ... I have never even seen a com directory on my RPM-based Fedora... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
Lennart Poettering mzerq...@0pointer.de writes: IMHO, libexecdir is not part of this at all... we already have: If upstream's build scripts support the use of %{_libexecdir} then that is the most appropriate place to configure it (eg. passing --libexecdir=%{libexecdir}/%{name} to autotools configure). If upstream's build scripts do not support that, %{_libdir}/%{name} is a valid second choice. It's all about the choice of lib instead of %{_libdir}. The problem is that in the absence of libexec, there's no consistent location to put helper binaries. %{_libdir}/%{name} doesn't work - depending on distribution and architecture, your files are now either in lib/name, lib32/name or lib64/name. Far from ideal. Lennart's position that fundamental system infrastructure belongs in lib makes sense, since there's absolutely no good reason for multilibing those components. Yes, absolutely. That's key here: multilibbing things should be the exception, and used where strictly *necessary*, not the default for all files. That means that libraries should go to %{_libdir} since they need to be available for both 32bit and 64bit. However, non-library stuff such as internal binaries, or anything else arch specific should not be in %{_libdir}, but in lib/. Multilib is not pretty, it's primarily just a hack to fix one specific problem, and one shouldn't let this specific spill in an otherwise fine design. Hence: use multilib if you must for a specific file, but only then. Having been a 64bit RHEL and Fedora user for years, I couldn't agree more. And I believe a firm policy is needed for consistency and to avoid confusion. One concrete example is Nagios plugins. They're helper binaries and are put in %{_libdir}/nagios/plugins. To keep things consistent one the same architecture (having all plugins in the same location to avoid complicating configuration), even noarch plugins are built as architecture dependent packages. That shouldn't be necessary. Regards, -- Trond H. Amundsen t.h.amund...@usit.uio.no Center for Information Technology Services, University of Oslo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, 20.12.12 23:24, Toshio Kuratomi (a.bad...@gmail.com) wrote: 2) we have to pressure upstream projects to needlessly complicate their code and buildsystem with stuff like $libexecdir variables in their autofoo, which resolve to /usr/libexec on Fedora/RHEL but just /usr/lib or something on other distros - which is kind of an imposition on upstreams Since neither of these things are required by the packaging guidelines, I believe the premise of your argument is deeply flawed. 1) As i've said before, there is no packaging guideline requirement that maintainers restrict helper applications to libexec. Helper apps can go in either %{_libdir} or %{_libexecdir} (and really, helper apps should be able to go in %{_prefix}/lib under a simple multilib exemption rather easily now as well.) 2) the systemd exceptions allows placing files in %{_prefix}/lib rather than %{_libdir} (the exceptions allow both putting the helper apps in there which would generally be okay with just a multilib exception and the unit files which are arch specific data and therefore usually go in %{_libdir} and therefore needed a special exception). The only reason people can drag %{_libexecdir} in to this discussion is that helper binaries are allowed in either %{_libdir} or %{_libexecdir}. In the context of forcing people to use a specific directory not specified by standards its meaningless because %{_libdir} is a suitable alternative. it is simply wrong to place internal binaries in %{_libdir}. internal binaries should not be subject to multlib'ed dirs, the same way as binaries in bin/ are not... 3) lennert is not asking that we give permission for packages to use something other than %{_libexecdir} if upstream doesn't support it. He's asking us to forbid use of libexecdir within fedora packages no matter what the package maintainer and upstream support. Not true. I am saying the guidelines should guide people to do the right thing, but not be force too much. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
Interesting previous discussions about /usr/libexec: http://lists.debian.org/debian-devel/2005/05/thrd2.html#00401 http://www.redhat.com/archives/rhl-devel-list/2005-May/thread.html#00240 FreeBSD has /usr/libexec[1], and it's part of historical Unix, although I cannot find when it was first introduced. It's not in V7 which uses /usr/lib directly for auxiliary uucp binaries. [1] http://www.freebsd.org/doc/handbook/dirstructure.html 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: Summary/Minutes for today's FESCo meeting (2012-12-19)
On 12/21/2012 02:24 PM, Lennart Poettering wrote: On Fri, 21.12.12 05:38, Ralf Corsepius (rc040...@freenet.de) wrote: On 12/21/2012 12:27 AM, Matthew Garrett wrote: On Thu, Dec 20, 2012 at 10:30:37PM +, Richard W.M. Jones wrote: Thanks, but I think the bit I'm mising is why can't systemd use libexec? (Apart from their declaration that libexec is wrong or not the de-facto standard they themselves made up, which is not a reason). Because libexec doesn't exist on most other distributions, libexecdir is part of the GNU standards for ages. The GNU standard is kinda flawed and nobody uses that as 1:1. Utter nonsense. I mean, /usr/etc? /usr/var?? /us/com??? Defaults == they need to be adapted to a specific distro's requirements. It's probably more interesting in looking at the more realistic standards, such as FHS, and on what is actually really implemented, rather than on GNU which is really mostly theory... I mean, not even Debian as the distro closest to GNU follows much of that... Read it again. It's a guideline distros need to adapt to their demands. And guess what? All distros have done so, and RH also has done so until this UseMove crap came alone and FUBARed Linux (I know your opinion differs, but you will not be able to change my mind on it), I disagree. systemd simply hasn't taken libexecdir into account in its design and now is trying to propagate their oversight/mistake as standard instead of making their works compliant with _our_ distro's demands. No, we just look around, and try to do something that is not specific to a distro, somewhat sane and follows the schemes of the established to the level where they make sense. That's not how I perceive what you are doing. You should start to consider that there are reasons behind how things are - Many people have invested their brains into it for decades. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On 12/20/2012 11:54 PM, Matthew Garrett wrote: On Fri, Dec 21, 2012 at 05:38:17AM +0100, Ralf Corsepius wrote: I disagree. systemd simply hasn't taken libexecdir into account in its design and now is trying to propagate their oversight/mistake as standard instead of making their works compliant with _our_ distro's demands. libexec doesn't exist in any published version of the FHS, and even the draft of 3.0 makes it clear that it's optional. Our use of libexec is non-standard, not systemd's use of lib. fyi: libexec has been critical to virtualization for quite some time... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 04:22:47PM +, Matthew Garrett wrote: On Fri, Dec 21, 2012 at 10:49:19AM -0500, Don Dutile wrote: On 12/20/2012 11:54 PM, Matthew Garrett wrote: libexec doesn't exist in any published version of the FHS, and even the draft of 3.0 makes it clear that it's optional. Our use of libexec is non-standard, not systemd's use of lib. fyi: libexec has been critical to virtualization for quite some time... I think Don is referring to the helper binaries that go into /usr/libexec: $ rpm -ql qemu-common | grep libexec /usr/libexec/qemu-bridge-helper $ rpm -ql libvirt-daemon | grep libexec /usr/libexec/libvirt_iohelper /usr/libexec/libvirt_lxc /usr/libexec/libvirt_parthelper [Not relevant to this discussion, but on RHEL /usr/libexec/qemu-kvm is the location of the KVM binary, designed to make it clear that this should not be run directly by RHEL customers (at least, not if they desire support).] How do you manage to do anything on Ubuntu? The files above don't appear to be packaged at all on Debian (Wheezy beta 4). However the versions of libvirt, qemu etc on Debian are rather old compared to what we're shipping in F18. They might predate those files being needed. Ubuntu has really poor virt support, and IME just copies stuff partially and badly from Debian. It doesn't seem to be their focus and libguestfs at least is often broken. 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: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 12:42:14AM -0800, Toshio Kuratomi wrote: However, you also miss my point. Adam's message was saying that the guidelines forced people to use libexecdir and then went on to point out the drawbacks of forcing specifically libexecdir on upstreams that didn't have that coded in. So, as I said, in that context it's meaningless to bring up arguments that are only addressed to libexecdir because %{_libdir} is an alternative. I think you miss my point. Where consistency across architectures is desired, %{_libdir} isn't an option, so in the absence of an exception the guidelines force people to use libexec. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 04:37:59PM +, Richard W.M. Jones wrote: On Fri, Dec 21, 2012 at 04:22:47PM +, Matthew Garrett wrote: On Fri, Dec 21, 2012 at 10:49:19AM -0500, Don Dutile wrote: fyi: libexec has been critical to virtualization for quite some time... I think Don is referring to the helper binaries that go into /usr/libexec: $ rpm -ql qemu-common | grep libexec /usr/libexec/qemu-bridge-helper $ rpm -ql libvirt-daemon | grep libexec /usr/libexec/libvirt_iohelper /usr/libexec/libvirt_lxc /usr/libexec/libvirt_parthelper Is the path user visible in any way? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 04:55:09PM +, Matthew Garrett wrote: On Fri, Dec 21, 2012 at 04:37:59PM +, Richard W.M. Jones wrote: On Fri, Dec 21, 2012 at 04:22:47PM +, Matthew Garrett wrote: On Fri, Dec 21, 2012 at 10:49:19AM -0500, Don Dutile wrote: fyi: libexec has been critical to virtualization for quite some time... I think Don is referring to the helper binaries that go into /usr/libexec: $ rpm -ql qemu-common | grep libexec /usr/libexec/qemu-bridge-helper $ rpm -ql libvirt-daemon | grep libexec /usr/libexec/libvirt_iohelper /usr/libexec/libvirt_lxc /usr/libexec/libvirt_parthelper Is the path user visible in any way? If used, /usr/libexec/qemu-bridge-helper is encoded directly in the libvirt XML. So is libvirt_lxc. (So is /usr/libexec/qemu-kvm, on RHEL). Not sure about the other two libvirt_* files. It appears that libvirtd simply runs those. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 05:09:00PM +, Richard W.M. Jones wrote: On Fri, Dec 21, 2012 at 04:55:09PM +, Matthew Garrett wrote: Is the path user visible in any way? If used, /usr/libexec/qemu-bridge-helper is encoded directly in the libvirt XML. So is libvirt_lxc. (So is /usr/libexec/qemu-kvm, on RHEL). Are those expected to be portable between systems? If not, it's not a problem. If so, you probably want to rethink the use of libexec. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 05:13:17PM +, Matthew Garrett wrote: On Fri, Dec 21, 2012 at 05:09:00PM +, Richard W.M. Jones wrote: On Fri, Dec 21, 2012 at 04:55:09PM +, Matthew Garrett wrote: Is the path user visible in any way? If used, /usr/libexec/qemu-bridge-helper is encoded directly in the libvirt XML. So is libvirt_lxc. (So is /usr/libexec/qemu-kvm, on RHEL). Are those expected to be portable between systems? If not, it's not a problem. If so, you probably want to rethink the use of libexec. There's no requirement for portability, XML files are considered to be specific to the host they're installed on, so its not a portability problem. Contrary to what Don says earlier in the thread, I think the choice of lib vs libexec has essentially zero impact on virtualization. It is just a choice distro packagers make Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, Dec 20, 2012 at 09:16:00PM -0800, Adam Williamson wrote: I've never seen any distro take any notice of this standard whatsoever. Well, if you don't count Red Hat Linux, Fedora, and Red Hat Enterprise Linux -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 04:55:09PM +, Matthew Garrett wrote: On Fri, Dec 21, 2012 at 04:37:59PM +, Richard W.M. Jones wrote: On Fri, Dec 21, 2012 at 04:22:47PM +, Matthew Garrett wrote: On Fri, Dec 21, 2012 at 10:49:19AM -0500, Don Dutile wrote: fyi: libexec has been critical to virtualization for quite some time... I think Don is referring to the helper binaries that go into /usr/libexec: $ rpm -ql qemu-common | grep libexec /usr/libexec/qemu-bridge-helper $ rpm -ql libvirt-daemon | grep libexec /usr/libexec/libvirt_iohelper /usr/libexec/libvirt_lxc /usr/libexec/libvirt_parthelper Is the path user visible in any way? Yes no. The iohelper/parthelper binaries are not user visible things. They're purely internal helpers libvirt uses. The libvirt_lxc binary does appear in the XML emulator/usr/libexec/libvirt_lxc/emulator. The libvirt_lxc binary is the host-side helper, akin to /bin/qemu-system-x86_64 in QEMU/KVM world. We put it under /usr/libexec though because it isn't a binary end users will ever directly invoke. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 04:59:59PM +, Daniel P. Berrange wrote: The libvirt_lxc binary does appear in the XML emulator/usr/libexec/libvirt_lxc/emulator. The libvirt_lxc binary is the host-side helper, akin to /bin/qemu-system-x86_64 in QEMU/KVM world. We put it under /usr/libexec though because it isn't a binary end users will ever directly invoke. That seems fine. libexec is a perfectly reasonable place for it to be on Fedora, and other distributions can stick them in lib/libvirt. Where they're this opaque there's no problem. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On 20 December 2012 22:16, Adam Williamson awill...@redhat.com wrote: On Fri, 2012-12-21 at 06:09 +0100, Ralf Corsepius wrote: On 12/21/2012 05:54 AM, Matthew Garrett wrote: On Fri, Dec 21, 2012 at 05:38:17AM +0100, Ralf Corsepius wrote: I disagree. systemd simply hasn't taken libexecdir into account in its design and now is trying to propagate their oversight/mistake as standard instead of making their works compliant with _our_ distro's demands. libexec doesn't exist in any published version of the FHS, FHS != GCS http://www.gnu.org/prep/standards/standards.html#Directory-Variables IIRC, it's around there for at approx 20 years. I've never seen any distro take any notice of this standard whatsoever. This is in fact the first reference I've seen to it in any context. The historical reason that Red Hat/Fedora used /usr/libexec and various other oddities was to conform to the GCS in Red Hat's early days. A file standard needed to be chosen that worked for things and GCS was setup for all the GNU tools. RPM was then coded to be GCS friendly etc etc. That said, the need to keep following the FHS, GCS, or the JanitorsFileLayoutStandard is up to FESCO after a reasoned debate.. which seems fairly lacking on everyone's side at the moment. Go take a week off and come back in January. Or better yet, how about going outside the Fedora bubble and conversing with the relevant people in Debian, SuSE, etc and getting FHS back on track because we are all having the same issues about this and we keep solving them seperately versus together. -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, 2012-12-21 at 12:30 -0500, Matthew Miller wrote: On Thu, Dec 20, 2012 at 09:16:00PM -0800, Adam Williamson wrote: I've never seen any distro take any notice of this standard whatsoever. Well, if you don't count Red Hat Linux, Fedora, and Red Hat Enterprise Linux I should probably have been more precise about that, but what I meant was this: I've been following this list for several years now and not once in any of the many and colorful arguments we have about path names and locations do I recall anyone citing this GNU filesystem 'standard'. I don't recall it coming up once in the /usr move saga, for instance. An archive search shows I'm slightly wrong, but not very much so: https://www.google.ca/search?q=gnu coding standards+site%3Ahttps%3A%2F %2Flists.fedoraproject.org%2Fpipermail%2Fdevel it appears to have been cited in about 10 threads since 2004. And most of those in a 'it's an interesting reference but nothing we have to follow' sort of way. Indeed, in an earlier discussion on this topic, Toshio wrote explicitly that we don't consider GCS as canonical: 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 https://lists.fedoraproject.org/pipermail/devel/2011-June/152343.html In passing, a post from Toshio back in February explains rather more clearly than anything in this thread why systemd unit files shouldn't go in libexec anyway, and so why this whole side-thread is kind of irrelevant: So I have to admit here that I have no idea why systemd is using $libexecdir here. The definition of libexecdir does not support the storing of unit files...unit files are declarative, not executable. It sounds like upstream systemd wants to use $(exec_prefix)/lib/systemd for the unit files and is attempting to shoehorn those into libexecdir because some distros set libexecdir to ${exec_prefix}/lib whereas some distros on some arches set libdir to ${exec_prefix}lib64 This is incorrect use of libexecdir. They should just use ${exec_prefix}/lib if that is the place that makes the most sense. https://lists.fedoraproject.org/pipermail/devel/2012-February/163024.html -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 04:47:58PM +, Matthew Garrett wrote: On Fri, Dec 21, 2012 at 12:42:14AM -0800, Toshio Kuratomi wrote: However, you also miss my point. Adam's message was saying that the guidelines forced people to use libexecdir and then went on to point out the drawbacks of forcing specifically libexecdir on upstreams that didn't have that coded in. So, as I said, in that context it's meaningless to bring up arguments that are only addressed to libexecdir because %{_libdir} is an alternative. I think you miss my point. Where consistency across architectures is desired, %{_libdir} isn't an option, so in the absence of an exception the guidelines force people to use libexec. Please re-read my email to see how I addressed your concerns in my first paragraph. This paragraph was to show how my email was responding to the context in Adam's email. -Toshio pgpjQ41lPkL75.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
Lennart Poettering (mzerq...@0pointer.de) said: it is simply wrong to place internal binaries in %{_libdir}. internal binaries should not be subject to multlib'ed dirs, the same way as binaries in bin/ are not... I would note I have seen cases where helper binaries actually needed to be arch-specific and in $prefix/$libdir. I think it was bonobo? In any case, I agree - my proposal was that packages that use non-multilibbed helper binaries should be free to put them in *one of* $prefix/lib or $prefix/libexec, as long as they remain consistent. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 10:33:27AM -0800, Adam Williamson wrote: On Fri, 2012-12-21 at 12:30 -0500, Matthew Miller wrote: On Thu, Dec 20, 2012 at 09:16:00PM -0800, Adam Williamson wrote: I've never seen any distro take any notice of this standard whatsoever. Well, if you don't count Red Hat Linux, Fedora, and Red Hat Enterprise Linux I should probably have been more precise about that, but what I meant was this: I've been following this list for several years now and not once in any of the many and colorful arguments we have about path names and locations do I recall anyone citing this GNU filesystem 'standard'. I don't recall it coming up once in the /usr move saga, for instance. Just a note -- I try to mention the GNU Coding Standards everytime libexec has come up in the context of not being standardized. I may not catch each and every thread that mentions libexec because it's not always relevant to the discussion (if the discussion isn't about libexec in standards). No sense bringing the same discussion up repeatedly once the posters appear to remember it ;-) (And sometimes, I just don't see a post where it would make sense to add a mention of the GNU Coding Standards... especially if I'm slogging through an email backlog after a vacation or conference ;-) The GNU Coding Standards mention even made it into one of the UsrMove threads. I think you found that in your google search but just neglected to clearly articulate it (and of course, I probably didn't call enough attention to it since I've posted about the relation before and they are mentioned in the Filesystem Layout section of the Packaging Guidelines). http://lists.fedoraproject.org/pipermail/devel/2012-February/163024.html An archive search shows I'm slightly wrong, but not very much so: https://www.google.ca/search?q=gnu coding standards+site%3Ahttps%3A%2F %2Flists.fedoraproject.org%2Fpipermail%2Fdevel it appears to have been cited in about 10 threads since 2004. And most of those in a 'it's an interesting reference but nothing we have to follow' sort of way. Indeed, in an earlier discussion on this topic, Toshio wrote explicitly that we don't consider GCS as canonical: 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 https://lists.fedoraproject.org/pipermail/devel/2011-June/152343.html nod Although your use of canonical above is open to interpretation (In retrospect, I suppose that definitive is also). I'd apply the word canonical for Fedora to be what's written in the Fedora Packaging Guidelines. In turn, the Packaging Guidelines consider the FHS to be the foundation of where files belong on the filesystems with a few tweaks that are explicitly mentioned in the Packaging Guidelines. The tweak for libexec was drawn from the GNU Coding Standards. Many of the other paths in the FHS are listed in the GNU Coding Standards and serve the same purpose in both documents so you can sometimes read the GNU Coding Standards for a broader understanding of why the placement of a particular type of file in a particular path is appropriate. But if you want to base a decision on something that's in the GUN Coding Standard but not in the FHS or Packaging Guidelines, then you should be taking it to the FPC for them to evaluate whether to add it to the Fedora Packaging Guidelines as a new tweak/exception to the general follow FHS rule. In passing, a post from Toshio back in February explains rather more clearly than anything in this thread why systemd unit files shouldn't go in libexec anyway, and so why this whole side-thread is kind of irrelevant: So I have to admit here that I have no idea why systemd is using $libexecdir here. The definition of libexecdir does not support the storing of unit files...unit files are declarative, not executable. It sounds like upstream systemd wants to use $(exec_prefix)/lib/systemd for the unit files and is attempting to shoehorn those into libexecdir because some distros set libexecdir to ${exec_prefix}/lib whereas some distros on some arches set libdir to ${exec_prefix}lib64 This is incorrect use of libexecdir. They should just use ${exec_prefix}/lib if that is the place that makes the most sense. https://lists.fedoraproject.org/pipermail/devel/2012-February/163024.html Yep, thanks for finding that quote. I'm not sure what variable systemd currently using in its build scripts but that still applies here. -Toshio pgpWy2aovJdiR.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
Once upon a time, Bill Nottingham nott...@redhat.com said: In any case, I agree - my proposal was that packages that use non-multilibbed helper binaries should be free to put them in *one of* $prefix/lib or $prefix/libexec, as long as they remain consistent. As a sys admin (and an OCD one at that), I'd prefer to keep things that are run separate from other stuff. Except when they are multi-lib, I think executables should be kept out of lib/ or lib64/; that's exactly what libexec/ is for. There used to be (not just talking about Linux) bunches of executables all over the place (/lib and /usr/lib, /etc, and so on), but they have moved to more appropriate places (such as sbin/ directories) over the years (except for /usr/lib/sendmail, which apparently will live forever, but at least it is just a symlink now). IMHO putting executables in lib/ or lib64/ is a regression to the past. Another package that has always seemed odd to me is mailman; why are all the commands (that are expected to be run from the command line, not just as internal helpers) in /usr/lib/mailman/bin? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 02:17:39PM -0500, Bill Nottingham wrote: Lennart Poettering (mzerq...@0pointer.de) said: it is simply wrong to place internal binaries in %{_libdir}. internal binaries should not be subject to multlib'ed dirs, the same way as binaries in bin/ are not... I would note I have seen cases where helper binaries actually needed to be arch-specific and in $prefix/$libdir. I think it was bonobo? In any case, I agree - my proposal was that packages that use non-multilibbed helper binaries should be free to put them in *one of* $prefix/lib or $prefix/libexec, as long as they remain consistent. I'll see if I can write this into the packaging Guidelines -- the FPC members were just worried that packagers would attempt to use a multilib exemption without a manual review as a way to circumvent non-trivial packaging issues: The upstream library build scripts just use hardcoded /usr/lib. I haven't heard of anyone using multilib (what is multilib anyway?) so I guess I can just install it to /usr/lib. But something like helper binaries that would ordinarily be installed into %{_libexecdir} are always multilib exempt. Just be sure the (sub)package they're in does not have other, multiilib content. If in doubt, ask. might be clear enough to pass. I'll open the FPC ticket now. And on another note, adamw and myself decided that in the spirit of Christmas, we're going to attempt to let this thread die. You can look forward to zero new posts from the two of us on this thread. Happy Holidays everyone, here's wishing everyone a flame free inbox for Christmas :-) -Toshio pgpyCScGNmuDS.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, Dec 20, 2012 at 01:54:57AM +, Matthew Garrett wrote: On Wed, Dec 19, 2012 at 11:56:36PM +0100, Kevin Kofler wrote: Yuck! I really don't see why we should be granting this type of exceptions. libexec and share exist for a reason. Helper binaries need to be in libexec, unit files in share, I think allowing systemd to dump everything (and in particular 64-bit stuff) to lib is setting a horrible precedent. Unit files need to be in /, so moving them would either require creating a /share for distributions that haven't merged /usr or putting up with inconsistent naming between distributions. Consistency is a virtue and the chances of getting anyone else to accept /share are minimal, so /lib it is. Meanwhile, libexec's not part of any non-draft version of the FHS and doesn't exist on most other distributions, and the path of the helper binaries has ended up in a bunch of unit files. So, similar problems. What benefit do you see in modifying systemd? Can someone summarise the trac ticket: https://fedorahosted.org/fpc/ticket/158 and the above reply, because none of it seems to make much sense to me. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Wed, Dec 19, 2012 at 11:56 PM, Kevin Kofler kevin.kof...@chello.at wrote: Tomas Mraz wrote: * AGREED: 1. systemd is granted an exception to put helper applications in /usr/lib/systemd (t8m, 19:03:17) * AGREED: 2. the systemd unit files of all the packages are granted an exception to be under /usr/lib/systemd (t8m, 19:03:33) Yuck! I really don't see why we should be granting this type of exceptions. libexec and share exist for a reason. Helper binaries need to be in libexec, unit files in share, I think allowing systemd to dump everything (and in particular 64-bit stuff) to lib is setting a horrible precedent. Please read the meeting log for the full rationale. In short: (I hope I'm not mischaracterizing; FESCo members, please correct me if anything is incorrect or misleading.) The exceptions were granted to avoid the impact of fixing this on developers, and more importantly on users (the /usr/lib/systemd paths for units are in various documentation, and even worse the paths to binaries in /usr/lib/systemd are embedded in users' copies of units placed in /etc/; moving the binaries would break users' configuration). Several (but not all?) FESCo members were concerned about setting a bad precedent, and in fact there was a proposal to approve an explicit statement to the effect that similar exceptions will not be granted in the future. This explicit statement was not approved; the most common objection was that FESCo explicitly saying that the established policies are to be respected is redundant and unnecessary. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
Le Jeu 20 décembre 2012 02:54, Matthew Garrett a écrit : On Wed, Dec 19, 2012 at 11:56:36PM +0100, Kevin Kofler wrote: Yuck! I really don't see why we should be granting this type of exceptions. libexec and share exist for a reason. Helper binaries need to be in libexec, unit files in share, I think allowing systemd to dump everything (and in particular 64-bit stuff) to lib is setting a horrible precedent. Unit files need to be in /, so moving them would either require creating a /share for distributions that haven't merged /usr or putting up with inconsistent naming between distributions. systemd people spearheaded the /usr merge Their main argument was cleaning up the filesystem layout! And now they've inconvenienced everyone else, they want to avoid the cleaning up consequences their side??? What is the logic here? I could understand postponing cleaning up for F19, but systemd really need to eat its own dogfood and lead by example. We've merged /usr now. /usr merge cost was supposed to be offset by cleanups wins. If we refuse to do the cleanups and keep all the historic warts because some other distributions haven't merged, why the heck did we accept the /usr merge burden in the first place? This is design by committee where all the bad options are chosen simultaneously to avoid annoying anyone. Can we stick to the single evil we've already chosen instead please? Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, Dec 20, 2012 at 02:28:48PM +, Richard W.M. Jones wrote: On Thu, Dec 20, 2012 at 01:54:57AM +, Matthew Garrett wrote: On Wed, Dec 19, 2012 at 11:56:36PM +0100, Kevin Kofler wrote: Yuck! I really don't see why we should be granting this type of exceptions. libexec and share exist for a reason. Helper binaries need to be in libexec, unit files in share, I think allowing systemd to dump everything (and in particular 64-bit stuff) to lib is setting a horrible precedent. Unit files need to be in /, so moving them would either require creating a /share for distributions that haven't merged /usr or putting up with inconsistent naming between distributions. Consistency is a virtue and the chances of getting anyone else to accept /share are minimal, so /lib it is. Meanwhile, libexec's not part of any non-draft version of the FHS and doesn't exist on most other distributions, and the path of the helper binaries has ended up in a bunch of unit files. So, similar problems. What benefit do you see in modifying systemd? Can someone summarise the trac ticket: https://fedorahosted.org/fpc/ticket/158 and the above reply, because none of it seems to make much sense to me. The effect of this is: FPC will write into the Guidelines (probably where libexec is mentioned since that's where the note about being able to use %{_libdir} as an alternative to %{_libexecdir} is ) that the systemd helper binaries and unitfiles have been granted a special exception to install into %{_prefix}/lib instead of %{_libdir}. This should mean that nothing changes in the systemd packages or in packages which provide unitfiles. They are already installing into those locations. -Toshio pgp6VnkFvIvnP.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, Dec 20, 2012 at 12:02:22PM -0800, Toshio Kuratomi wrote: The effect of this is: FPC will write into the Guidelines (probably where libexec is mentioned since that's where the note about being able to use %{_libdir} as an alternative to %{_libexecdir} is ) that the systemd helper binaries and unitfiles have been granted a special exception to install into %{_prefix}/lib instead of %{_libdir}. This should mean that nothing changes in the systemd packages or in packages which provide unitfiles. They are already installing into those locations. Thanks, but I think the bit I'm mising is why can't systemd use libexec? (Apart from their declaration that libexec is wrong or not the de-facto standard they themselves made up, which is not a reason). Also Matthew said Unit files need to be in /, but libexec is in /, unless the whole UsrMove thing was pointless. 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: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, Dec 20, 2012 at 10:30:37PM +, Richard W.M. Jones wrote: Thanks, but I think the bit I'm mising is why can't systemd use libexec? (Apart from their declaration that libexec is wrong or not the de-facto standard they themselves made up, which is not a reason). Because libexec doesn't exist on most other distributions, and systemd aims to offer consistent interfaces across distributions. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Dec 20, 2012 3:16 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Thu, Dec 20, 2012 at 12:02:22PM -0800, Toshio Kuratomi wrote: The effect of this is: FPC will write into the Guidelines (probably where libexec is mentioned since that's where the note about being able to use %{_libdir} as an alternative to %{_libexecdir} is ) that the systemd helper binaries and unitfiles have been granted a special exception to install into %{_prefix}/lib instead of %{_libdir}. This should mean that nothing changes in the systemd packages or in packages which provide unitfiles. They are already installing into those locations. Thanks, but I think the bit I'm mising is why can't systemd use libexec? (Apart from their declaration that libexec is wrong or not the de-facto standard they themselves made up, which is not a reason). There is no reason they could not use libexec for the helper binaries. As I said in the meeting, libexec is somewhat of a red herring here. The packaging guidelines already allow substituting subdirs of %_libdir for %_libexecdir. What's in question is being able to use /usr/lib for arch specific 64bit binaries on 64 bit multilib enabled boxes. Since helper binaries are not going to have two versions for multilib this portion of the exception follows naturally from the decision that non multilib packages can be given exceptions to use /usr/lib even on x86_64. Also Matthew said Unit files need to be in /, but libexec is in /, unless the whole UsrMove thing was pointless. Unit files won't go in libexec. They'd go in _libdir or in _datadir ordinarily depending on whether they're arch-specific or arch independent data. This Matt not speak to your objection but I felt it's a clarification that needed making. -Toshio 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, 20.12.12 12:02, Toshio Kuratomi (a.bad...@gmail.com) wrote: On Thu, Dec 20, 2012 at 02:28:48PM +, Richard W.M. Jones wrote: On Thu, Dec 20, 2012 at 01:54:57AM +, Matthew Garrett wrote: On Wed, Dec 19, 2012 at 11:56:36PM +0100, Kevin Kofler wrote: Yuck! I really don't see why we should be granting this type of exceptions. libexec and share exist for a reason. Helper binaries need to be in libexec, unit files in share, I think allowing systemd to dump everything (and in particular 64-bit stuff) to lib is setting a horrible precedent. Unit files need to be in /, so moving them would either require creating a /share for distributions that haven't merged /usr or putting up with inconsistent naming between distributions. Consistency is a virtue and the chances of getting anyone else to accept /share are minimal, so /lib it is. Meanwhile, libexec's not part of any non-draft version of the FHS and doesn't exist on most other distributions, and the path of the helper binaries has ended up in a bunch of unit files. So, similar problems. What benefit do you see in modifying systemd? Can someone summarise the trac ticket: https://fedorahosted.org/fpc/ticket/158 and the above reply, because none of it seems to make much sense to me. The effect of this is: FPC will write into the Guidelines (probably where libexec is mentioned since that's where the note about being able to use %{_libdir} as an alternative to %{_libexecdir} is ) that the systemd helper binaries and unitfiles have been granted a special exception to install into %{_prefix}/lib instead of %{_libdir}. This should mean that nothing changes in the systemd packages or in packages which provide unitfiles. They are already installing into those locations. I'd much prefer if FPC/FESCO would actually just do the right thing, forget about libexec (since it's a pointless, sometimes dangerous, confused thing and not available on any other distribution), and declare that lib/package is the place for package-specific stuff and share/package the place that is shared between packages. Just making systemd the exception sounds like chickening out from the real solution which is to end this Fedoraism. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, Dec 20, 2012 at 04:05:36PM -0800, Toshio Kuratomi wrote: As I said in the meeting, libexec is somewhat of a red herring here. The packaging guidelines already allow substituting subdirs of %_libdir for %_libexecdir. What's in question is being able to use /usr/lib for arch specific 64bit binaries on 64 bit multilib enabled boxes. Make /usr/lib be the native arch location on all systems, and put any 32-bit libs in /usr/lib32 on 64-bit systems. Problem solved! *ducks* -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, Dec 20, 2012 at 04:05:36PM -0800, Toshio Kuratomi wrote: On Dec 20, 2012 3:16 PM, Richard W.M. Jones rjo...@redhat.com wrote: Thanks, but I think the bit I'm mising is why can't systemd use libexec? (Apart from their declaration that libexec is wrong or not the de-facto standard they themselves made up, which is not a reason). There is no reason they could not use libexec for the helper binaries. Well, from a practical perspective, there is - it'd break existing user configurations. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 01:06:13AM +0100, Lennart Poettering wrote: On Thu, 20.12.12 12:02, Toshio Kuratomi (a.bad...@gmail.com) wrote: FPC will write into the Guidelines (probably where libexec is mentioned since that's where the note about being able to use %{_libdir} as an alternative to %{_libexecdir} is ) that the systemd helper binaries and unitfiles have been granted a special exception to install into %{_prefix}/lib instead of %{_libdir}. This should mean that nothing changes in the systemd packages or in packages which provide unitfiles. They are already installing into those locations. I'd much prefer if FPC/FESCO would actually just do the right thing, forget about libexec (since it's a pointless, sometimes dangerous, confused thing and not available on any other distribution), and declare that lib/package is the place for package-specific stuff and share/package the place that is shared between packages. Just making systemd the exception sounds like chickening out from the real solution which is to end this Fedoraism. Well really it's us not wanting to fight to make you do the right thing any longer. If you want us to take a stand please continue to talk about your way being the one and only right way until someone's heroic enough to stand up to your attitude. /me will stop trying to help you guys out by actively seeking to reevaluate old conflicts in which you formerly lost out in light of new guidelines that might change how we would fairly evaluate your situation. -Toshio pgpFFSUvIftjY.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, 2012-12-20 at 17:50 -0800, Toshio Kuratomi wrote: Just making systemd the exception sounds like chickening out from the real solution which is to end this Fedoraism. Well really it's us not wanting to fight to make you do the right thing any longer. If you want us to take a stand please continue to talk about your way being the one and only right way until someone's heroic enough to stand up to your attitude. Ahem. Isn't your own first sentence suggesting that *your* way is the one and only right way? I don't see how you can attack Lennart for having a firm belief about what's the 'right way' when you also seem to have a firm belief about what's the 'right way'... /me will stop trying to help you guys out by actively seeking to reevaluate old conflicts in which you formerly lost out in light of new guidelines that might change how we would fairly evaluate your situation. -Toshio -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 1:06 AM, Lennart Poettering mzerq...@0pointer.de wrote: declare that lib/package is the place for package-specific stuff and share/package the place that is shared between packages. If this is supposed to be within current FHS (and not a proposal to abandon it), the above is a gross misunderstanding of the lib vs. share distinction of FHS. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, Dec 20, 2012 at 06:07:58PM -0800, Adam Williamson wrote: On Thu, 2012-12-20 at 17:50 -0800, Toshio Kuratomi wrote: Just making systemd the exception sounds like chickening out from the real solution which is to end this Fedoraism. Well really it's us not wanting to fight to make you do the right thing any longer. If you want us to take a stand please continue to talk about your way being the one and only right way until someone's heroic enough to stand up to your attitude. Ahem. Isn't your own first sentence suggesting that *your* way is the one and only right way? I don't see how you can attack Lennart for having a firm belief about what's the 'right way' when you also seem to have a firm belief about what's the 'right way'... The FPC Guidelines give package maintainers the option of using %{_libexecdir}, %{_libdir}. The recent changes that I worked on allow %{_prefix}/lib in certain cases. When FPC at large decided that portions of what systemd wanted to do still didn't completely fall under those cases, I took the request from FPC that FESCo simply grant a special exception for systemd to FESCo. So if you're arguing that my firm belief is also a right way or the highway, belief then you aren't arguing about the use of lib, libexec, and lib64 anymore. You're opening up a much larger conversation about whether top-down or bottom-up decision making is the direction that Fedora should be taking in the future; whether Fedora management should decide on one and only one way to do things and then force every packager to do things that way. But if you want to go that route on this question, then it should be noted that FPC ruled that the use that systemd makes of %{_prefix}/lib was wrong under the prior guidelines but the systemd maintainers refused to make their package conform. So while you might pose that question it's not likely to have a more desirable outcome for the systemd package maintainers than what they have now. -Toshio pgpEdR76gKW8S.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, 2012-12-20 at 18:48 -0800, Toshio Kuratomi wrote: On Thu, Dec 20, 2012 at 06:07:58PM -0800, Adam Williamson wrote: On Thu, 2012-12-20 at 17:50 -0800, Toshio Kuratomi wrote: Just making systemd the exception sounds like chickening out from the real solution which is to end this Fedoraism. Well really it's us not wanting to fight to make you do the right thing any longer. If you want us to take a stand please continue to talk about your way being the one and only right way until someone's heroic enough to stand up to your attitude. Ahem. Isn't your own first sentence suggesting that *your* way is the one and only right way? I don't see how you can attack Lennart for having a firm belief about what's the 'right way' when you also seem to have a firm belief about what's the 'right way'... The FPC Guidelines give package maintainers the option of using %{_libexecdir}, %{_libdir}. The recent changes that I worked on allow %{_prefix}/lib in certain cases. When FPC at large decided that portions of what systemd wanted to do still didn't completely fall under those cases, I took the request from FPC that FESCo simply grant a special exception for systemd to FESCo. So if you're arguing that my firm belief is also a right way or the highway, belief then you aren't arguing about the use of lib, libexec, and lib64 anymore. You're opening up a much larger conversation about whether top-down or bottom-up decision making is the direction that Fedora should be taking in the future; whether Fedora management should decide on one and only one way to do things and then force every packager to do things that way. But if you want to go that route on this question, then it should be noted that FPC ruled that the use that systemd makes of %{_prefix}/lib was wrong under the prior guidelines but the systemd maintainers refused to make their package conform. So while you might pose that question it's not likely to have a more desirable outcome for the systemd package maintainers than what they have now. It seemed perfectly clear from context that what Lennart was arguing is that the guidelines should be changed and we should stop using this /usr/libexec directory which no-one outside of RH-derived distros has adopted, and which is thus a barrier to cross-distro operation of projects like systemd. It doesn't seem like an optimal situation if Fedora's guidelines require systemd to do something which doesn't make sense on other systemd-based distros at all. A systemd-specific exception works for systemd, fine, but it doesn't really seem to address the root problem. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, 2012-12-20 at 18:54 -0800, Adam Williamson wrote: A systemd-specific exception works for systemd, fine, but it doesn't really seem to address the root problem. To further elaborate: the 'root problem', it seems to me, is that this 'Fedoraism' as Lennart calls it results in one of two things: 1) we have to carry downstream patches or spec file stuff to relocate things to /usr/libexec (and, possibly, tell other things that those things have been relocated) - which is against https://fedoraproject.org/wiki/Staying_close_to_upstream_projects or: 2) we have to pressure upstream projects to needlessly complicate their code and buildsystem with stuff like $libexecdir variables in their autofoo, which resolve to /usr/libexec on Fedora/RHEL but just /usr/lib or something on other distros - which is kind of an imposition on upstreams All this for the rather questionable benefit of having a specifically defined place for helper-scripts-not-meant-to-be-executed-directly, which gains us...what, exactly, over just putting them in /usr/lib/(appname) or /usr/share/(appname) or whatever? I don't see that libexec is actually giving us some kind of huge win to justify the inconveniences. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, 2012-12-20 at 19:05 -0800, Adam Williamson wrote: On Thu, 2012-12-20 at 18:54 -0800, Adam Williamson wrote: A systemd-specific exception works for systemd, fine, but it doesn't really seem to address the root problem. To further elaborate: the 'root problem', it seems to me, is that this 'Fedoraism' as Lennart calls it results in one of two things: 1) we have to carry downstream patches or spec file stuff to relocate things to /usr/libexec (and, possibly, tell other things that those things have been relocated) - which is against https://fedoraproject.org/wiki/Staying_close_to_upstream_projects or: 2) we have to pressure upstream projects to needlessly complicate their code and buildsystem with stuff like $libexecdir variables in their autofoo, which resolve to /usr/libexec on Fedora/RHEL but just /usr/lib or something on other distros - which is kind of an imposition on upstreams All this for the rather questionable benefit of having a specifically defined place for helper-scripts-not-meant-to-be-executed-directly, which gains us...what, exactly, over just putting them in /usr/lib/(appname) or /usr/share/(appname) or whatever? I don't see that libexec is actually giving us some kind of huge win to justify the inconveniences. Hm, I missed the point that the exception is for lib/foo vs. %libdir/foo (arched vs. non-arched). That makes it a more complex three-way argument. But I think the point about libexecdir being pointless still stands. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
libexec in history [was Re: Summary/Minutes for today's FESCo meeting (2012-12-19)]
On Thu, Dec 20, 2012 at 06:54:24PM -0800, Adam Williamson wrote: It seemed perfectly clear from context that what Lennart was arguing is that the guidelines should be changed and we should stop using this /usr/libexec directory which no-one outside of RH-derived distros has adopted, and which is thus a barrier to cross-distro operation of projects like systemd. It's worth knowing the history here. Libexec isn't completely out of the blue -- it comes from GNU. For whatever reason, FHS was resistant to accepting libexec (but somewhat ironically!) the BSDs picked it up, and as I understand it, liked it so much that it's one of the reasons the FHS failed to become more than a Linux standard. Debian discussed following Red Hat / Fedora with libexec, but decided that the way to go about doing that was to work upstream to change the FHS. But, the FHS process was pretty much stalled and directionless at that point, so nothing went anywhere -- not on the merits of the proposal, but just because of the state of that project. There's been a reason attempt to revive the FHS under the aegis of the Linux Foundation, and there's a FHS 3.0 draft, which, in fact, includes libexec. http://www.linuxbase.org/betaspecs/fhs/fhs/ch04s07.html Although the Debian conversation was long ago, what I remember is a general agreement that it was a good idea but that there was a process to go through. I won't put myself in the prediction business here, but I wouldn't be _surprised_ if Debian and Ubuntu adopt libexec if FHS 3.0 ever happens. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, Dec 20, 2012 at 07:05:20PM -0800, Adam Williamson wrote: A systemd-specific exception works for systemd, fine, but it doesn't really seem to address the root problem. To further elaborate: the 'root problem', it seems to me, is that this 'Fedoraism' as Lennart calls it results in one of two things: 1) we have to carry downstream patches or spec file stuff to relocate things to /usr/libexec (and, possibly, tell other things that those things have been relocated) - which is against https://fedoraproject.org/wiki/Staying_close_to_upstream_projects Goes both ways -- I just came across a SuSE mailing list discussion about patching programs to use lib/packagename instead of libexec/packagename. Of course, the GNU stuff is amenable to changes at the ./configure level, so changing that might just be a matter of redefining %{_libexecdir} and doing a gigantic mass rebuild. But that seems like pretty pointless churn. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 4:05 AM, Adam Williamson awill...@redhat.com wrote: On Thu, 2012-12-20 at 18:54 -0800, Adam Williamson wrote: A systemd-specific exception works for systemd, fine, but it doesn't really seem to address the root problem. To further elaborate: the 'root problem', it seems to me, is that this 'Fedoraism' as Lennart calls it results in one of two things: 1) we have to carry downstream patches or spec file stuff to relocate things to /usr/libexec (and, possibly, tell other things that those things have been relocated) Per my reading of the FHS (but this is ultimately up to FPC), binaries that other things refer to belong strictly in /usr/bin and nowhere in /usr/lib*, so the more complex case should never arise. What is the left is the simpler case of relocating files within a package, something that happens quite frequently for other reasons as well. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, 2012-12-21 at 04:22 +0100, Miloslav Trmač wrote: On Fri, Dec 21, 2012 at 4:05 AM, Adam Williamson awill...@redhat.com wrote: On Thu, 2012-12-20 at 18:54 -0800, Adam Williamson wrote: A systemd-specific exception works for systemd, fine, but it doesn't really seem to address the root problem. To further elaborate: the 'root problem', it seems to me, is that this 'Fedoraism' as Lennart calls it results in one of two things: 1) we have to carry downstream patches or spec file stuff to relocate things to /usr/libexec (and, possibly, tell other things that those things have been relocated) Per my reading of the FHS (but this is ultimately up to FPC), binaries that other things refer to belong strictly in /usr/bin and nowhere in /usr/lib*, so the more complex case should never arise. What is Oh, sure, 'should'...=) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, 20 Dec 2012 19:10:45 -0800 Adam Williamson awill...@redhat.com wrote: Hm, I missed the point that the exception is for lib/foo vs. %libdir/foo (arched vs. non-arched). That makes it a more complex three-way argument. But I think the point about libexecdir being pointless still stands. IMHO, libexecdir is not part of this at all... we already have: If upstream's build scripts support the use of %{_libexecdir} then that is the most appropriate place to configure it (eg. passing --libexecdir=%{libexecdir}/%{name} to autotools configure). If upstream's build scripts do not support that, %{_libdir}/%{name} is a valid second choice. It's all about the choice of lib instead of %{_libdir}. I'd love to see this changed/fixed down the road, but it's a lot of documentation and moving around. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, 20 Dec 2012, Adam Williamson wrote: All this for the rather questionable benefit of having a specifically defined place for helper-scripts-not-meant-to-be-executed-directly, which gains us...what, exactly, over just putting them in /usr/lib/(appname) or /usr/share/(appname) or whatever? If you put it in /usr/lib/foo/ on 64bit machines, then I can see phasing out libexec, but as an upstream with some scripts but also binary helpers, I have consciously avoid the /usr/lib{64} usage and kept things in libexec. In fact, I moved some stuff from /usr/lib*/foo/ to libexec to get less headaches. I don't see that libexec is actually giving us some kind of huge win to justify the inconveniences. Sorry, what is the inconvenience of libexec? Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, 2012-12-20 at 23:01 -0500, Paul Wouters wrote: On Thu, 20 Dec 2012, Adam Williamson wrote: All this for the rather questionable benefit of having a specifically defined place for helper-scripts-not-meant-to-be-executed-directly, which gains us...what, exactly, over just putting them in /usr/lib/(appname) or /usr/share/(appname) or whatever? If you put it in /usr/lib/foo/ on 64bit machines, then I can see phasing out libexec, but as an upstream with some scripts but also binary helpers, I have consciously avoid the /usr/lib{64} usage and kept things in libexec. In fact, I moved some stuff from /usr/lib*/foo/ to libexec to get less headaches. I don't see that libexec is actually giving us some kind of huge win to justify the inconveniences. Sorry, what is the inconvenience of libexec? The bit of my mail that you cut out? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On 12/21/2012 12:27 AM, Matthew Garrett wrote: On Thu, Dec 20, 2012 at 10:30:37PM +, Richard W.M. Jones wrote: Thanks, but I think the bit I'm mising is why can't systemd use libexec? (Apart from their declaration that libexec is wrong or not the de-facto standard they themselves made up, which is not a reason). Because libexec doesn't exist on most other distributions, libexecdir is part of the GNU standards for ages. Other distros set --libexecdir=/usr/lib instead of providing a separate one. and systemd aims to offer consistent interfaces across distributions. I disagree. systemd simply hasn't taken libexecdir into account in its design and now is trying to propagate their oversight/mistake as standard instead of making their works compliant with _our_ distro's demands. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 05:38:17AM +0100, Ralf Corsepius wrote: I disagree. systemd simply hasn't taken libexecdir into account in its design and now is trying to propagate their oversight/mistake as standard instead of making their works compliant with _our_ distro's demands. libexec doesn't exist in any published version of the FHS, and even the draft of 3.0 makes it clear that it's optional. Our use of libexec is non-standard, not systemd's use of lib. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On 12/21/2012 01:15 AM, Matthew Miller wrote: On Thu, Dec 20, 2012 at 04:05:36PM -0800, Toshio Kuratomi wrote: As I said in the meeting, libexec is somewhat of a red herring here. The packaging guidelines already allow substituting subdirs of %_libdir for %_libexecdir. What's in question is being able to use /usr/lib for arch specific 64bit binaries on 64 bit multilib enabled boxes. Make /usr/lib be the native arch location on all systems, and put any 32-bit libs in /usr/lib32 on 64-bit systems. Problem solved! The subdirectories being used for multi-archs can more or less be arbitrarily choosen. Fedora/RH once have chosen ../lib and ../lib64 Ubuntu/Debian seem to have chosen ../lib32 and ../lib64 and seem to be using /usr/lib for primary arch. As a side-effect of this choice, Ubuntu/Debian have separate directories for multi-arched directories, and a non-multi-arched, primary-arched /usr/lib, while Fedora only has multi-arched subdir and a non-multi-arched /usr/lib. That said, Fedora actually doesn't have a notion of primary-arch. The issues we are discussing here actually are cludges to press works, which didn't take such a strict separation into account rsp. which rely on a primary arch, into Fedora. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, Dec 20, 2012 at 08:57:58PM -0700, Kevin Fenzi wrote: IMHO, libexecdir is not part of this at all... we already have: If upstream's build scripts support the use of %{_libexecdir} then that is the most appropriate place to configure it (eg. passing --libexecdir=%{libexecdir}/%{name} to autotools configure). If upstream's build scripts do not support that, %{_libdir}/%{name} is a valid second choice. It's all about the choice of lib instead of %{_libdir}. The problem is that in the absence of libexec, there's no consistent location to put helper binaries. %{_libdir}/%{name} doesn't work - depending on distribution and architecture, your files are now either in lib/name, lib32/name or lib64/name. Far from ideal. Lennart's position that fundamental system infrastructure belongs in lib makes sense, since there's absolutely no good reason for multilibing those components. I'd love to see this changed/fixed down the road, but it's a lot of documentation and moving around. The situation right now is that it's impossible to write good cross-distribution documentation. We should just do it for the sake of future ease. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On 12/21/2012 05:54 AM, Matthew Garrett wrote: On Fri, Dec 21, 2012 at 05:38:17AM +0100, Ralf Corsepius wrote: I disagree. systemd simply hasn't taken libexecdir into account in its design and now is trying to propagate their oversight/mistake as standard instead of making their works compliant with _our_ distro's demands. libexec doesn't exist in any published version of the FHS, FHS != GCS http://www.gnu.org/prep/standards/standards.html#Directory-Variables IIRC, it's around there for at approx 20 years. and even the draft of 3.0 makes it clear that it's optional. We all know about the strong positions of the FHS. It is the least common denominator of all distros and deliberately weakly formulated ;) Our use of libexec is non-standard, C.f above. I disagree. not systemd's use of lib. I disagree again. systemd is in its infancy and needs to do its homework. As I see it, like many other works, they simply did not take the GCS and the side-effects of multi-arching into account. Now they are pressing the limitations of their design into Fedora and are forcing Fedora to resort to cludges. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, 2012-12-21 at 06:09 +0100, Ralf Corsepius wrote: On 12/21/2012 05:54 AM, Matthew Garrett wrote: On Fri, Dec 21, 2012 at 05:38:17AM +0100, Ralf Corsepius wrote: I disagree. systemd simply hasn't taken libexecdir into account in its design and now is trying to propagate their oversight/mistake as standard instead of making their works compliant with _our_ distro's demands. libexec doesn't exist in any published version of the FHS, FHS != GCS http://www.gnu.org/prep/standards/standards.html#Directory-Variables IIRC, it's around there for at approx 20 years. I've never seen any distro take any notice of this standard whatsoever. This is in fact the first reference I've seen to it in any context. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 06:09:10AM +0100, Ralf Corsepius wrote: On 12/21/2012 05:54 AM, Matthew Garrett wrote: On Fri, Dec 21, 2012 at 05:38:17AM +0100, Ralf Corsepius wrote: I disagree. systemd simply hasn't taken libexecdir into account in its design and now is trying to propagate their oversight/mistake as standard instead of making their works compliant with _our_ distro's demands. libexec doesn't exist in any published version of the FHS, FHS != GCS http://www.gnu.org/prep/standards/standards.html#Directory-Variables IIRC, it's around there for at approx 20 years. So? and even the draft of 3.0 makes it clear that it's optional. We all know about the strong positions of the FHS. It is the least common denominator of all distros and deliberately weakly formulated ;) Our use of libexec is non-standard, C.f above. I disagree. The GCS describe the behaviour of code written to the GCS, nothing more. The majority of the software we ship doesn't conform to them. not systemd's use of lib. I disagree again. systemd is in its infancy and needs to do its homework. As I see it, like many other works, they simply did not take the GCS and the side-effects of multi-arching into account. They're not a GNU project, and so there's no reason for them to follow the GCS. There's also no reason for it to support multiarch - you're never going to have two copies of systemd installed simultaneously. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On 12/21/2012 06:16 AM, Adam Williamson wrote: On Fri, 2012-12-21 at 06:09 +0100, Ralf Corsepius wrote: On 12/21/2012 05:54 AM, Matthew Garrett wrote: On Fri, Dec 21, 2012 at 05:38:17AM +0100, Ralf Corsepius wrote: I disagree. systemd simply hasn't taken libexecdir into account in its design and now is trying to propagate their oversight/mistake as standard instead of making their works compliant with _our_ distro's demands. libexec doesn't exist in any published version of the FHS, FHS != GCS http://www.gnu.org/prep/standards/standards.html#Directory-Variables IIRC, it's around there for at approx 20 years. I've never seen any distro take any notice of this standard whatsoever. Bummer ... you have been living in a vacuum for the last 20 years and have never been coding any a little more complex package ? RPM respects the GCS ever since RPM exists, autoconf honors it ever since autoconf and the GCS exists and all major GNU and many more projects honor it. Some even make heavy active use of it (Most prominently: GCC). This is in fact the first reference I've seen to it in any context. ... Sigh/ Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On 12/21/2012 06:36 AM, Matthew Garrett wrote: On Fri, Dec 21, 2012 at 06:09:10AM +0100, Ralf Corsepius wrote: On 12/21/2012 05:54 AM, Matthew Garrett wrote: On Fri, Dec 21, 2012 at 05:38:17AM +0100, Ralf Corsepius wrote: I disagree. systemd simply hasn't taken libexecdir into account in its design and now is trying to propagate their oversight/mistake as standard instead of making their works compliant with _our_ distro's demands. libexec doesn't exist in any published version of the FHS, FHS != GCS http://www.gnu.org/prep/standards/standards.html#Directory-Variables IIRC, it's around there for at approx 20 years. So? Next the FHS, it is one of the fundamental standards, which define the basis of all packaging works on Linux/GNU and thus also the FPG. and even the draft of 3.0 makes it clear that it's optional. We all know about the strong positions of the FHS. It is the least common denominator of all distros and deliberately weakly formulated ;) Our use of libexec is non-standard, C.f above. I disagree. The GCS describe the behaviour of code written to the GCS, nothing more. The majority of the software we ship doesn't conform to them. I disagree again. Most packages silently conform its path conventions, only few don't and only few explicitly exploit it. not systemd's use of lib. I disagree again. systemd is in its infancy and needs to do its homework. As I see it, like many other works, they simply did not take the GCS and the side-effects of multi-arching into account. They're not a GNU project, and so there's no reason for them to follow the GCS. Sure, but there is hardly any reason for a package to not adopt it. If systemd was an arbitrary package, it hardly wouldn't have an alternative to adapt to it, because it in its current shape violates the FPG. There's also no reason for it to support multiarch - you're never going to have two copies of systemd installed simultaneously. Agreed, it's unlikely to happen you'll run 2 in parallel, but you'll never know. It would not be the first project, who refused to apply libexecdir until they suddenly could not avoid it for technical reasons. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 07:16:12AM +0100, Ralf Corsepius wrote: On 12/21/2012 06:36 AM, Matthew Garrett wrote: So? Next the FHS, it is one of the fundamental standards, which define the basis of all packaging works on Linux/GNU and thus also the FPG. No, it defines the GNU project's standards for their own projects. Fedora's not a GNU project, and nor are most of the packages we ship. The GCS describe the behaviour of code written to the GCS, nothing more. The majority of the software we ship doesn't conform to them. I disagree again. Most packages silently conform its path conventions, only few don't and only few explicitly exploit it. The path convention is a small part of the GCS. They're not a GNU project, and so there's no reason for them to follow the GCS. Sure, but there is hardly any reason for a package to not adopt it. Sure there is - most distributions don't have libexec, and so software that depends on it will have inconsistent paths on different distributions. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
-Toshio On Dec 20, 2012 7:05 PM, Adam Williamson awill...@redhat.com wrote: On Thu, 2012-12-20 at 18:54 -0800, Adam Williamson wrote: A systemd-specific exception works for systemd, fine, but it doesn't really seem to address the root problem. To further elaborate: the 'root problem', it seems to me, is that this 'Fedoraism' as Lennart calls it results in one of two things: 1) we have to carry downstream patches or spec file stuff to relocate things to /usr/libexec (and, possibly, tell other things that those things have been relocated) - which is against https://fedoraproject.org/wiki/Staying_close_to_upstream_projects or: 2) we have to pressure upstream projects to needlessly complicate their code and buildsystem with stuff like $libexecdir variables in their autofoo, which resolve to /usr/libexec on Fedora/RHEL but just /usr/lib or something on other distros - which is kind of an imposition on upstreams Since neither of these things are required by the packaging guidelines, I believe the premise of your argument is deeply flawed. 1) As i've said before, there is no packaging guideline requirement that maintainers restrict helper applications to libexec. Helper apps can go in either %{_libdir} or %{_libexecdir} (and really, helper apps should be able to go in %{_prefix}/lib under a simple multilib exemption rather easily now as well.) 2) the systemd exceptions allows placing files in %{_prefix}/lib rather than %{_libdir} (the exceptions allow both putting the helper apps in there which would generally be okay with just a multilib exception and the unit files which are arch specific data and therefore usually go in %{_libdir} and therefore needed a special exception). The only reason people can drag %{_libexecdir} in to this discussion is that helper binaries are allowed in either %{_libdir} or %{_libexecdir}. In the context of forcing people to use a specific directory not specified by standards its meaningless because %{_libdir} is a suitable alternative. 3) lennert is not asking that we give permission for packages to use something other than %{_libexecdir} if upstream doesn't support it. He's asking us to forbid use of libexecdir within fedora packages no matter what the package maintainer and upstream support. -Toshio All this for the rather questionable benefit of having a specifically defined place for helper-scripts-not-meant-to-be-executed-directly, which gains us...what, exactly, over just putting them in /usr/lib/(appname) or /usr/share/(appname) or whatever? I don't see that libexec is actually giving us some kind of huge win to justify the inconveniences. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, 2012-12-20 at 23:24 -0800, Toshio Kuratomi wrote: Since neither of these things are required by the packaging guidelines, I believe the premise of your argument is deeply flawed. 1) As i've said before, there is no packaging guideline requirement that maintainers restrict helper applications to libexec. Helper apps can go in either %{_libdir} or %{_libexecdir} (and really, helper apps should be able to go in %{_prefix}/lib under a simple multilib exemption rather easily now as well.) The guideline is written to suggest that use of libexecdir is strongly favoured, and use of libdir is distinctly a fallback position: Fedora's rpm includes a macro for libexecdir, %{_libexecdir}. Packagers are highly encouraged to store libexecdir files in a package-specific subdirectory of %{_libexecdir}, such as %{_libexecdir}/%{name}. Note 'highly encouraged'. If upstream's build scripts do not support that, %{_libdir}/%{name} is a valid second choice. Note 'valid second choice'. The text is clearly intentionally written to suggest that libexecdir is much the preferred option and libdir/name a regrettable fallback plan. 3) lennert is not asking that we give permission for packages to use something other than %{_libexecdir} if upstream doesn't support it. He's asking us to forbid use of libexecdir within fedora packages no matter what the package maintainer and upstream support. Well, you can gloss it as 'forbid' or 'stop promoting'. Same difference, but it reads a lot differently. Let's face it, package maintainers and upstreams usually only support libexecdir because RH-land pushes it. I do apologize for somewhat derailing things towards the libexecdir discussion, though, as I missed the point about the real question here being between /lib/foo and $libdir/foo . The libexecdir thing is kind of a tangent and probably should be split out if we're going to keep talking about it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, Dec 20, 2012 at 11:24:09PM -0800, Toshio Kuratomi wrote: 2) the systemd exceptions allows placing files in %{_prefix}/lib rather than %{_libdir} (the exceptions allow both putting the helper apps in there which would generally be okay with just a multilib exception and the unit files which are arch specific data and therefore usually go in %{_libdir} and therefore needed a special exception). The only reason people can drag %{_libexecdir} in to this discussion is that helper binaries are allowed in either %{_libdir} or %{_libexecdir}. In the context of forcing people to use a specific directory not specified by standards its meaningless because %{_libdir} is a suitable alternative. I think the libexec discussion is fairly relevant. Right now a package can drop binaries in libexecdir and have a consistent path regardless of the architecture, which is valuable. However, doing so results in inconsistencies with other distributions which don't provide libexecdir. This is clearly suboptimal, and it's reasonable to ask that the packaging guidelines recognise that and handle it without requiring additional exceptions - if a package wouldn't require an exception to install binaries in libexec, it shouldn't need an exception install binaries in lib. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
Tomas Mraz wrote: * AGREED: 1. systemd is granted an exception to put helper applications in /usr/lib/systemd (t8m, 19:03:17) * AGREED: 2. the systemd unit files of all the packages are granted an exception to be under /usr/lib/systemd (t8m, 19:03:33) Yuck! I really don't see why we should be granting this type of exceptions. libexec and share exist for a reason. Helper binaries need to be in libexec, unit files in share, I think allowing systemd to dump everything (and in particular 64-bit stuff) to lib is setting a horrible precedent. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Wed, Dec 19, 2012 at 11:56:36PM +0100, Kevin Kofler wrote: Yuck! I really don't see why we should be granting this type of exceptions. libexec and share exist for a reason. Helper binaries need to be in libexec, unit files in share, I think allowing systemd to dump everything (and in particular 64-bit stuff) to lib is setting a horrible precedent. Unit files need to be in /, so moving them would either require creating a /share for distributions that haven't merged /usr or putting up with inconsistent naming between distributions. Consistency is a virtue and the chances of getting anyone else to accept /share are minimal, so /lib it is. Meanwhile, libexec's not part of any non-draft version of the FHS and doesn't exist on most other distributions, and the path of the helper binaries has ended up in a bunch of unit files. So, similar problems. What benefit do you see in modifying systemd? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel