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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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 ☁☁☁
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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?
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
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,
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
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
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}
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
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
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
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
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
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
-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
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
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
===
#fedora-meeting: FESCO (2012-12-19)
===
Meeting started by t8m at 18:00:39 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2012-12-19/fedora-meeting.2012-12-19-18.00.log.html
.
Meeting
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
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
72 matches
Mail list logo
