7:06 a.m.
Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 17:00UTC (1:00pm EDT, 19:00 CEST) in #fedora-meeting on
irc.freenode.net.
Links to all tickets below can be found at:
https://fedorahosted.org/fesco/report/9
= Followups =
#topic #615 Strategy for services that do not have systemd native unit files
.fesco 615
https://fedorahosted.org/fesco/ticket/615
#topic #896 Refine Feature process
.fesco 896
https://fedorahosted.org/fesco/ticket/896
#topic #969 libexecdir guideline conflicts with extant packages
.fesco 969
https://fedorahosted.org/fesco/ticket/969
= New business =
None.
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
1:24 p.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
===================================
#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...
.
Meeting summary
---------------
* init process (t8m, 18:01:19)
* #615 Strategy for services that do not have systemd native unit files
(t8m, 18:04:23)
* LINK: http://paste.stg.fedoraproject.org/2660/ <- list of packages
(notting, 18:14:27)
* Push updates which change the sysv init to systemd unit as NTH to
F18 now did not get enough votes. (t8m, 18:27:28)
* AGREED: Changing the sysv init scripts to systemd units is highly
encouraged even to provenpackagers willing to help. We will revisit
the situation 1 week before F19 branch point to see if we can just
have provenpackagers to finish them, or set deadline. (t8m,
18:35:03)
* #896 Refine Feature process (t8m, 18:36:02)
* discussion deferred waiting for concrete proposal (t8m, 18:37:10)
* #969 libexecdir guideline conflicts with extant packages (t8m,
18:38:15)
* LINK: https://fedorahosted.org/fpc/ticket/158#comment:12
(abadger1999, 18:39:18)
* 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)
* Next meeting chair (t8m, 19:10:37)
* Next FESCO meeting will be on Jan 2nd 2013 (t8m, 19:15:01)
* ACTION: mmaslano will chair on 2nd January meeting (t8m, 19:15:31)
* ACTION: sgallagh will chair on 9th January meeting (t8m, 19:16:03)
* Open Floor (t8m, 19:16:15)
Meeting ended at 19:19:25 UTC.
Action Items
------------
* mmaslano will chair on 2nd January meeting
* sgallagh will chair on 9th January meeting
Action Items, by person
-----------------------
* mmaslano
* mmaslano will chair on 2nd January meeting
* sgallagh
* sgallagh will chair on 9th January meeting
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* t8m (82)
* abadger1999 (51)
* mitr (50)
* nirik (47)
* sgallagh (42)
* notting (32)
* mmaslano (18)
* halfline (15)
* mjg59 (8)
* zodbot (8)
* adamw (5)
* jwb (5)
* jreznik (2)
* pjones (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
----------------
18:00:39 <t8m> #startmeeting FESCO (2012-12-19)
18:00:39 <zodbot> Meeting started Wed Dec 19 18:00:39 2012 UTC. The chair is t8m.
Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:39 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:01:10 <t8m> #chair notting nirik mmaslano t8m pjones mitr jwb sgallagh
abadger1999
18:01:10 <zodbot> Current chairs: abadger1999 jwb mitr mmaslano nirik notting pjones
sgallagh t8m
18:01:16 * sgallagh is here
18:01:19 <t8m> #topic init process
18:01:25 <t8m> hi all
18:01:30 * nirik waves.
18:01:32 * notting is here
18:01:35 <mmaslano> hi
18:01:43 <jwb> hi
18:02:20 <mitr> Hello all
18:02:30 * abadger1999 here
18:03:02 <t8m> Welcome to last FESCo meeting before EOW :)
18:03:47 <t8m> I suppose we can start?
18:03:48 <sgallagh> Topic for Open Floor: if we survive Friday, should we restart
the epoch? /kidding
18:04:18 <t8m> We have only a few followups today.
18:04:23 <t8m> #topic #615 Strategy for services that do not have systemd native
unit files
18:04:27 * jreznik is lurking and and hoped to survive Friday too
18:04:29 <t8m> .fesco 615
18:04:33 <zodbot> t8m: #615 (Strategy for services that do not have systemd native
unit files) – FESCo - https://fedorahosted.org/fesco/ticket/615
18:05:31 <t8m> If there is still 150 packages that have unconverted init scripts I
suppose we cannot easily block them.
18:06:13 <t8m> (or quickly fix them if we weren't able to do this by this time)
18:06:57 <nirik> well, we are just going to need to keep plugging away, and at some
point decide we want to just mass commit/fix the last ones...
18:06:59 <mitr> I really hate that we have 3 (or is it more now?) different package
integration mechanisms.
18:07:10 <t8m> so perhaps we should close this ticket and say it is ongoing effort
and the packages should be converted when possible.
18:07:11 <mmaslano> 3?
18:07:11 <notting> mitr: integration mechanisms?
18:07:29 <mitr> notting: "ways an individual package plugs into the service
framework" or something
18:07:46 <notting> what's the third?
18:07:52 <mitr> mmaslano: SysV, systemd as of F15, systemd with more updates as
mentioned by Johan in the last comment
18:07:54 <nirik> there's really 150 left?
18:07:57 <nirik> % repoquery -qf /etc/init.d/\* | sort | uniq | wc -l
18:07:57 <nirik> 38
18:08:15 <mmaslano> maybe he counts bugs?
18:08:20 <mitr> s/Johan/Johann/ sorry
18:08:28 <t8m> nirik, hmm that looks much better than 150
18:08:53 <t8m> nirik, what's the count without the uniq?
18:09:12 <nirik> 44
18:09:24 <nirik> .bug 713562
18:09:31 <zodbot> nirik: Bug 713562 Tracker bug for SYSV to systemd conversion -
https://bugzilla.redhat.com/show_bug.cgi?id=713562
18:09:34 <mitr> 26 open bugs
18:10:02 <nirik> this seems to me something we could target for f19...
18:10:46 <t8m> nirik, any proposal?
18:11:17 <notting> nirik: two locations
18:11:22 <notting> # repoquery --repoid fedora -qf /etc/init.d/\*
/etc/rc.d/init.d/\* | sort | uniq | wc -l
18:11:22 <notting> 223
18:11:35 <nirik> ah ha
18:11:37 <t8m> ah
18:12:19 <nirik> proposal: keep plugging away at these, revisit later in f19 cycle
to see if we can just have provenpackagers finish them, or set deadline.
18:12:21 <abadger1999> ah -- /etc/rc.d/init.d is the canonical location;
/etc/init.d/ is a symlink for debian compat that some packages seem to use.
18:12:34 <jwb> nirik, +1
18:12:39 <abadger1999> nirik: +1
18:12:46 <sgallagh> nirik: +1
18:12:56 <mitr> If we want to set a deadline, we should set it ASAP to give
maintainers more time
18:12:57 <notting> nirik: syre, +1
18:13:02 <notting> nirik: 175 source rpms
18:13:02 <t8m> nirik, +1 although I feel that the situation won't be much better
later in f19 cycle
18:13:16 <t8m> mitr, +1
18:13:44 <nirik> well, I think we are down to ones that need provenpackagers or
prodding... or just simply don't update much.
18:14:02 <sgallagh> mitr: We're going to hit the same problem as in previous
releases: what do we do when that deadline passes?
18:14:09 <sgallagh> Historically the answer has been "nothing"
18:14:14 <t8m> nirik, there still might be some that are really nontrivial to
change
18:14:27 <notting> http://paste.stg.fedoraproject.org/2660/ <- list of packages
18:14:43 <nirik> also, some of those packages are fine... compat sysvinit ones.
18:14:50 <nirik> (which are pointless IMHO, but we allow them)
18:14:54 <mitr> Proposal: Ask everyone to convert their packages by F19 branch time;
packages that don't update then have automatically approved comaintainers (anyone
already sponsored is eligible - or do we want even unsponsored people with a sponsor
watching them as a possible new path to Fedora?)
18:14:54 <sgallagh> What is yum doing in there?
18:15:24 <adamw> on this topic - there are a few bugs proposed as NTH for F18 on the
basis that they want to get systemd conversions in
18:15:27 <t8m> sgallagh, I suppose it is a compat sysvinit subpackage
18:15:35 <adamw> anyone have an opinion on whether that's something we want to
be doing this late? or should we push them to f19?
18:15:36 <notting> sgallagh: yum-cron
18:15:39 <mitr> t8m: Can the conversion be more difficult than moving the init
script into /usr/libexec/my-private/package and running it from the .service file
18:15:40 <mmaslano> why at? I converted it long time ago
18:16:01 <t8m> adamw, I think pushing them to f19 is fine
18:16:04 <sgallagh> It might be useful to refine that search to rule out those
packages that have .service files.
18:16:04 <abadger1999> adamw: Leaf packages or core packages?
18:16:07 <t8m> mmaslano, compat subpackage
18:16:13 <mmaslano> ah sure
18:16:17 <abadger1999> core packages, I don't like the risk.
18:16:28 <adamw> abadger1999:
https://admin.fedoraproject.org/updates/srptools-0.0.4-16.fc18,rdma-2.0-6...
is the specific update.
18:16:33 <mitr> adamw: I'd prefer to defer them now, the service ordering impact
can be fairly disruptive
18:16:49 <notting> it's inifiniband. would anyone in fedora notice if it broke?
(only half kidding)
18:17:03 <sgallagh> adamw: I'm with mitr here. At this point it's probably
too risky
18:17:10 <nirik> mitr: I don't think that tells us what to do if there's no
comaintainers, etc... unless we want to add 'provenpackages will convert the rest'
or something (and then we need to find such people willing to do it. ;)
18:17:51 <sgallagh> nirik: I suggest we visit that if and when it becomes
necessary.
18:17:54 * abadger1999 wonders which of those packages contains the systemd unit files
18:18:10 <sgallagh> In that case, leaf packages can probably be blocked, and
non-leaf packages can be addressed by provenpackagers
18:18:29 * abadger1999 would like to let them through if they're leaf -- otherwise the
packager is stuck maintaining the old scripts through the life of f18.
18:18:35 * abadger1999 repoquerying
18:18:47 * nirik is with abadger1999 on that.
18:18:50 <mitr> nirik: Right, it's not a full solution, and we don't really
have one (except retiring the packages, which is radical, or finding individual volunteers
for this occasion, which I think mostly only prolongs the pain)
18:19:04 <adamw> sgallagh: mitr: abadger: thanks
18:19:07 <sgallagh> abadger1999: How do we define "leaf" in this
situation?
18:19:20 <nirik> non critpath, no other packages depend on it?
18:19:22 <adamw> so that's 2 for let them through and 2 for don't let them
through :)
18:19:23 <abadger1999> sgallagh: I'd be okay with anything up to
"not-critpath"
18:19:34 <sgallagh> abadger1999: Package dependencies don't necessarily imply
service ordering.
18:19:36 <mitr> abadger1999: We have branches for that, is it really a significant
hurdle?
18:19:52 <abadger1999> mitr: it's a time span...
18:20:12 <sgallagh> For example, if a samba conversion caused winbind to load at a
different time, it could break service user lookups
18:20:15 <sgallagh> (theoretically)
18:20:22 <abadger1999> ie: having to care about both systemd and sysv init scripts
for six more months than they would if the unit files go into f18.
18:21:06 <mitr> abadger1999: Ah, you're talking about the NTH. I still think
that merging git branches should not be a significant hurdle, but it does add some
complexity
18:21:27 <abadger1999> mitr: <nod>
18:21:42 <nirik> so, we are getting sidetracked here...
18:22:24 <nirik> on adamw's question, could we vote? allow systemd converts in
as NTH bugs now if they are non critpath
18:22:36 <abadger1999> +1
18:22:42 <sgallagh> Yeah, +1
18:22:43 <t8m> nirik, +0
18:22:48 <nirik> +1
18:23:13 * nirik also frankly feels it's getting almost too late for NTH's...
18:23:14 <mitr> -1 still
18:23:53 <jwb> 0
18:24:18 <mmaslano> 0
18:24:58 <t8m> pjones, notting?
18:25:14 <t8m> still can get 5 votes
18:25:24 <nirik> pjones is out this week. ;)
18:25:26 <notting> i'm +1
18:25:40 <nirik> so, looks like not enough votes to pass unless someone changes.
18:25:46 <t8m> ah then unfortunately not enough votes
18:26:46 <nirik> ok, and on the ticket then? any proposals or votes on existing
proposals?
18:27:16 <jwb> i'm still for your original proposal of working through the
existing packages during f19 (starting now of course)
18:27:20 <sgallagh> nirik: I'm still +1 for the original proposal
18:27:28 <t8m> #info Push updates which change the sysv init to systemd unit as NTH
to F18 now did not get enough votes.
18:28:05 <t8m> I see 5 votes for the original nirik's proposal
18:28:07 <sgallagh> FWIW, I think the end result of that is that the final decision
falls to the bugzappers to decide
18:28:38 <nirik> well, it's on us if we just keep carrying those packages with
sysvinit, or force them to be changed, or drop the packages entirely.
18:29:12 * abadger1999 still +1 to nirik's proposal.
18:29:12 <t8m> anybody wants to add or change votes to the original proposal?
18:30:50 <nirik> converting sysvinit scripts: a fun holiday task for any
provenpackager. ;)
18:31:01 <notting> i'm fine with just trying to work through them. we'll
likely need to support sysv scripts for some value of indefinitely for third-parties,
so... *shrug* if some packages in fedora still have them
18:31:18 <t8m> #agreed Changing the sysv init scripts to systemd units is highly
encouraged even to provenpackagers willing to help. We will revisit the situation later in
f19 cycle to see if we can just have provenpackagers to finish them, or set deadline.
18:31:44 <mitr> When is the "later" we will revisit?
18:32:09 <nirik> mitr: good question. we don't have much of a f19 schedule yet.
;(
18:32:28 <sgallagh> I suggest the branch, whenever we set that
18:32:34 <t8m> We have just feature submission deadline
18:33:20 <mitr> F19 branch time sounds fine
18:33:38 <nirik> sure, branch is fine whenever that is. Or just a week before then
18:33:44 * jreznik could mark it somewhere not to forget...
18:33:45 <mitr> Or 1 week before F19 branch, to allow the proven packagers to do the
work and avoid yet another inter-branch difference?
18:33:56 <t8m> mitr, +1
18:34:15 <abadger1999> +1
18:34:19 <sgallagh> mitr: +1
18:34:25 <t8m> #undo
18:34:25 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at
0x5fd4c6d0>
18:34:26 <nirik> +1
18:34:49 <mmaslano> +1
18:35:03 <t8m> #agreed Changing the sysv init scripts to systemd units is highly
encouraged even to provenpackagers willing to help. We will revisit the situation 1 week
before F19 branch point to see if we can just have provenpackagers to finish them, or set
deadline.
18:35:51 <t8m> anything else to this topic? if not, let's move on
18:36:02 <t8m> #topic #896 Refine Feature process
18:36:07 <t8m> .fesco 896
18:36:10 <zodbot> t8m: #896 (Refine Feature process) – FESCo -
https://fedorahosted.org/fesco/ticket/896
18:36:18 <mitr> I'm afraid I still have nothing, I hope to have a proposal done
during the holidays.
18:36:45 <t8m> OK, let's defer.
18:37:10 <t8m> #info discussion deferred waiting for concrete proposal
18:37:16 <sgallagh> +1 to defer. I think last week we said we intended to have a
higher-bandwidth discussion at FUDCON as well?
18:37:27 <nirik> yeah, and there's a bunch of ideas on the wiki page...
18:37:29 <t8m> sgallagh, this should be about smaller changes
18:37:34 <sgallagh> ok
18:37:37 <nirik> we just need some concrete ones written up.
18:37:51 <t8m> to be able to change things for F19 features
18:38:08 <t8m> next topic
18:38:15 <t8m> #topic #969 libexecdir guideline conflicts with extant packages
18:38:20 <t8m> .fesco 969
18:38:23 <zodbot> t8m: #969 (libexecdir guideline conflicts with extant packages)
– FESCo - https://fedorahosted.org/fesco/ticket/969
18:38:28 * nirik thinks abadger1999 had the background on this?
18:39:04 <abadger1999> yep -- fpc discussed this at their meeting this morning.
18:39:18 <abadger1999> https://fedorahosted.org/fpc/ticket/158#comment:12
18:39:42 <abadger1999> Basically, there's two different things that systemd
places in the wrong place (according to guidelines).
18:39:58 <abadger1999> FPC is willing to write in a special exception for systemd if
fesco wants them too.
18:40:11 <abadger1999> but the systemd maintainer's arguments failed to persuade
fpc.
18:40:25 <abadger1999> so it's up to us whether we wantto override them.
18:40:40 <nirik> which are the two things?
18:40:47 <nirik> and where should they go instead?
18:40:58 <abadger1999> the two areas are helper applications -- those could be
covered by a non-multilib exception.
18:41:09 <sgallagh> systemd is itself not multilib, correct?
18:41:15 <notting> sgallagh: correct
18:41:16 * nirik looks at the ticket, sorry
18:41:20 <mitr> IMO: /usr/lib/systemd is mostly FHS-incompliant; it should be split
over /etc,/usr/{bin,share,%{_lib},libexec}. /usr/lib/systemd is pretty close to
/opt/systemd, which is quite the opposite of FHS.
18:41:25 <abadger1999> the other are the unit files (carried by any service that
needs systemd to start).
18:41:28 <mitr> I'm fine with a systemd exception for historical reasons, but I
want the maintainers to commit to not using the /usr/lib/mypackage-mostfiles model for new
Fedora packages.
18:41:28 * jwb needs to head out early. apologies
18:41:30 <mitr> (Extending the requirement to structurally new features of systemd
would be pushing it, wouldn't it?)
18:41:37 <abadger1999> those would not be covered y a non-multilib exception.
18:41:58 <mitr> Is anyone suggesting we move all of the unit files out of
/usr/lib/systemd at this point?
18:41:59 <notting> Proposal: Applications can use /usr/lib/%{name} as a substitute
for /usr/libexec/%{name} for binaries executed at runtime in the package. Applications
should not mix the two usages in a single package.
18:42:29 <sgallagh> I'm opposed to moving the unit files at present. We've
got enough difficulty with adoption without moving things all over the place
18:42:38 <t8m> sgallagh, +1
18:42:38 <mitr> notting: -1 to a blanket thing like that.
18:42:51 <t8m> notting, -1 agree with mitr
18:43:07 <abadger1999> notting: I think half of that is already in the guidelines
revision that FPC made... (the part about /usr/lib substituting for libexec)
18:43:32 <mjg59> It seems a touch odd to argue about FHS compliance while
simultaneously arguing in favour of using libexec
18:43:37 <abadger1999> notting: the part about binaries executed at runtime would be
new.
18:43:38 <mitr> notting: (Either the file is an internal implementation detail of
the package, in which case moving it to /usr/libexec during packaging is very cheap, or it
is an inter-package API, in which case it has no business being in /usr/lib*)
18:43:42 <notting> abadger1999: ?
18:44:00 <abadger1999> notting: new to write down... not new in practice :-)
18:44:07 <notting> abadger1999: if the change is already made, then how is systemd
in violation for having binaries there?
18:44:44 <mitr> notting: What does the "at runtime" language mean, btw?
18:44:56 <abadger1999> notting: so what FPC wrote is that if fesco grants a
non-multilib exception, the helper binaries could go in /usr/lib instead of /usr/lib64 (or
/usr/libexec)
18:45:02 <abadger1999> notting: so there's two things:
18:45:12 <abadger1999> 1) fesco would need to grant a non-multilib exception
18:45:16 <notting> mitr: things executed "itself" during runtime, not
things directly executed by end users
18:45:20 <t8m> notting, If I read what FPC agreed upon correctly we need to
explicitly grant the exception to the package
18:45:30 <abadger1999> 2) fesco would also need to grant a special exception for the
unit files to stay in /usr/lib.
18:45:50 <t8m> abadger1999, I am +1 to both these proposals of FPC
18:46:09 <halfline> are the things in there really in /usr/lib or are they in /lib
which now happens to be in /usr since we've merged them?
18:46:17 <sgallagh> abadger1999: I don't understand why the unit files are in
/usr/lib either. Shouldn't they be in /var/lib[64] ?
18:46:42 <mitr> halfline: I can't see that it makes any difference to the
lib/lib64 question
18:46:44 <sgallagh> halfline: Is there a distinction at this point?
18:46:53 <t8m> #proposal 1. systemd is granted an exception to put helper
applications in /usr/lib/systemd
18:46:58 <notting> sgallagh: they started out in /lib because they were on the root
fs and there's no /share. *shrug*
18:46:59 <mitr> We sort of used /lib where there should have been a /share, but...
18:47:05 <abadger1999> sgallagh: So there's been conflicting stories over time
about what unit files "are".... I believe the last word was that the upstream
maintainers consider them arch-specific data files.
18:47:16 <abadger1999> although in practice we've never seen a unit file that
was arch specific.
18:47:20 <halfline> right that's my point, /lib is datadir if you don't have
/usr
18:47:28 <halfline> and datadir is where the units would go
18:47:40 <t8m> #proposal 2. the systemd unit files of all the packages are granted
an exception to be under /usr/lib/systemd
18:47:43 <abadger1999> If they're arch specific data, then they belong in
%{_libdir}
18:48:01 <abadger1999> If they're non-arch specific data, they belong in
%{_datadir}
18:48:11 * sgallagh nods
18:48:11 <abadger1999> If they are config they beolong in %{_sysconfdir}.
18:48:29 <halfline> they can't be arch specific, you shadow them in /etc if you
want to override them
18:48:33 <sgallagh> I'm pretty sure they're not config, since IIRC they are
overridden by placing a config in /etc
18:48:54 <sgallagh> Yeah, so that sounds to me like they qualify as
non-arch-specific data
18:49:06 <mitr> halfline: /etc can be arch specific - it is bound to the system in
question.
18:49:15 <t8m> they should be in %{_datadir} but they aren't for historical
reasons (being in rootfs)
18:49:16 <notting> i'm fine with granting both execptions, but i'd prefer
the stronger language about using /usr/lib instead of /usr/libexec
18:49:18 <abadger1999> sgallagh: it's a grey area of definition of what's
"config" -- but I don't think anyone wants to get into that at this meeting
;-)
18:49:44 <t8m> notting, can you be more specific how the proposal would like?
18:49:50 <sgallagh> abadger1999: I'm going to stick with: these files aren't
intended to be user-modified, they are effectively a visible internal default :)
18:49:56 <nirik> so, if we didn't grant any exception, where would those two
things end up? %{_libdir} ?
18:50:08 <mitr> sgallagh: They are an inter-package API, so not really
"internal"
18:50:11 <halfline> the packages i've seen either have /etc/something-x86_64 or
do things like put ${LIB} in file if they have arch specific stuff in /etc
18:50:13 <notting> t8m: pretty much what i proposed above?
18:50:29 <t8m> notting, but you don't specify systemd in that proposal
18:50:29 <abadger1999> nirik: as long as the maintainers tell us that they're
arch-specific data, we'd continue to say they need to go in %{_libdir}
18:50:39 <sgallagh> mitr: Well, it's not a perfect metaphor
18:50:40 <notting> t8m: let me rephrase
18:50:41 <mitr> nirik: Most of the unit files probably in %{_datadir}, executables
in %{_libdir} or libexec
18:50:51 <abadger1999> nirik: if the maitnainers switch to arch-indep data, we'd
say %{_datadir}.
18:51:05 <notting> t8m: i'm fine with your exceptions, but i would *prefer* a
generic exception for /usr/lib/foo as a substistute for /usr/libexec/foo, as proposed
above
18:51:11 <abadger1999> for the executables, %{_libexecdir} or %{_libdir} unless we
grant a non-multilib exception.
18:51:19 <notting> t8m: s/substitute/alternative/
18:51:40 <t8m> notting, hmm I'm -1 to that then
18:52:54 <sgallagh> Assuming we grant no exceptions, will the systemd maintainers
make the change. Assuming they do, how long will it take to accomplish (and will it affect
our F18 final release)?
18:52:59 <nirik> on the one hand, this seems like nitpicking... on the other hand, I
ask why they should be excepted... why can't they follow the rules.
18:53:08 <notting> in any case, i'm +1 to both of t8m's exceptions. doing
otherwise is stupid.
18:53:14 <nirik> big major -1 to changing anything in f18
18:53:24 <mitr> sgallagh: ... and what about all the user documentation that says
"copy file from /usr/lib/systemd/system* to /etc/"?
18:53:46 <abadger1999> Current aproved guidelines have: "If a package has been
granted an explicit exception from FESCo to permit it to not be multilib enabled, then it
may use %{_prefix}/lib instead of %{_libdir}." which is intended to modify this
current guideline http://fedoraproject.org/wiki/Packaging:Guidelines#Libexecdir
18:54:03 <sgallagh> mitr: I wasn't counseling that we should do it. Just asking
for the effort required if we did
18:54:39 <mitr> sgallagh: Right, it's just not "our" effort only that
would be affected.
18:54:46 <abadger1999> sgallagh: it will not affect f18 final -- too late for that
and fpc usually is okay if things are fixed at "Point in time and forwards."
18:55:01 <t8m> I am +1 to both of my proposals above as well
18:55:22 <mmaslano> surpsingly
18:55:22 <sgallagh> I'm +1 to the unit files for pragmatic reasons. +0 to the
helpers.
18:55:31 <mitr> Proposal: Both exceptions as mentioned in
https://fedorahosted.org/fpc/ticket/158#comment:12 are approved. At the same time FESCo
states that similar exceptions to newly introduced packages wiill not be granted; packages
are expected to place their files throughout /usr/{bin,share,lib*} per the FESCo
criteria.
18:55:39 <mmaslano> +1 to both t8ms proposals. We probably don't have better
proposal
18:56:02 <notting> mitr: -1 to that
18:56:04 * abadger1999 notes that FPC asked that both exceptions be granted or denied as a
group... separate was seen as being more confusing for no less work.
18:56:26 <mitr> sgallagh: Helper paths are by now embedded in the user-made copies
of /usr/lib/systemd unit files in /etc
18:56:38 <sgallagh> ugh
18:56:55 <sgallagh> Ok, then I don't really see any choice other than to grant
both exceptions.
18:57:03 <mitr> notting: Why? Do you thing the bin/lib/share distinctions of FHS
are not valuable?
18:57:47 <notting> mitr: i think arguing over internal usage of /usr/libexec/xxx vs
/usr/lib/xxx isn't worthwhile
18:58:21 <halfline> libexec isn't in FHS anyway is it? that's a redhatism
right?
18:58:29 <abadger1999> halfline: it's a GNU-ism.
18:58:42 <abadger1999> GNU coding standards specify libexecdir.
18:58:45 <mitr> notting: Maybe libexec vs.lib (but see the issue of /etc/ copies
above, we won't be able to multilib this in the future), but bin/lib/share?
18:59:15 <halfline> do any other major distros that ship GNU software have
/usr/libexec ?
18:59:36 <mitr> notting: I could understand a position that the FHS splits are
overall wrong and that we should abandon it in favor of per-package subtrees or something
18:59:52 * abadger1999 notes that he thinks discussing libexecdir is a sidetrack.
18:59:58 <halfline> fair enough
19:00:10 <t8m> abadger1999, +1
19:00:11 <abadger1999> this is really about %_libdir vs %_prefi/lib
19:00:15 <notting> mitr: it's mainly about forcing /usr/lib64 for internal
binaries, making them compile-time differences. see also python reading both locations
19:00:20 <mitr> halfline: BSDs
19:00:36 * nirik is a very weak +1 to the exceptions I guess. It anoys me that we are
basically granting this just because it would be work to do it correctly.
19:00:48 <halfline> seems like we should align with other linux distros and with FHS
before aligning with BSDs, but we can talk about it later
19:00:53 <mitr> nirik: I'm concerned about the user configuration breakage more
than the packagers work...
19:01:01 <nirik> mitr: yeah.
19:01:06 <nirik> and docs, and ...
19:01:08 <mjg59> halfline: libexec is only in the FHS 3.0 draft, not any actual FHS
19:01:12 <t8m> mitr, yeah, that's more important
19:01:27 <mitr> notting: Well as long as the paths are expected to appear in
user-maintained configuration, they don't belong anywhere in /usr/lib* IMHO
19:01:30 <mjg59> halfline: It's not widely used outside RH-derived
distributions
19:01:46 <halfline> yea
19:01:49 <mitr> t8m: how many votes were there for your proposal?
19:02:00 <halfline> so my thoughts are systemd as an upstream project still supports
separate /usr
19:02:10 <halfline> so the fact that it's upstream paths sort of reflect that
makes sense
19:02:12 <t8m> mitr, if sgallagh changes his vote for the second exception both
would pass
19:02:17 <halfline> and it seems silly to me we would override those upstram paths
19:02:20 <sgallagh> t8m: I already did
19:02:37 <t8m> sgallagh, oops I somehow overlooked it
19:02:44 <sgallagh> Probably should have said +1 explicitly though
19:02:50 <mitr> t8m: So let me add +1 to that, and then we talk only about the part
where we talk about the future policy?
19:03:00 <t8m> mitr, good idea
19:03:17 <t8m> #agreed 1. systemd is granted an exception to put helper applications
in /usr/lib/systemd
19:03:21 <nirik> IMHO there is no policy... if anything else wants to do this they
must specifically ask for exceptions.
19:03:33 <t8m> #agreed 2. the systemd unit files of all the packages are granted an
exception to be under /usr/lib/systemd
19:03:42 <mitr> nirik: OK, s/policy/statement of FESCo intent/
19:04:14 <halfline> so in my mind, the exception for projects should be if they run
in early boot up and they (from an upstream point of view want to support separate /usr)
they should get an exception in fedora
19:04:24 <t8m> mitr, go ahead with modified proposal
19:04:36 <halfline> since staying consistent with upstream (and by extension across
distros) is valuable enough of a reason for an exception
19:04:49 <mitr> Proposal: FESCo states that similar exceptions to newly introduced
packages wiill not be granted; packages are expected to place their files throughout
/usr/{bin,share,lib*} per the FHS criteria.
19:05:25 <t8m> mitr, +1
19:05:27 <nirik> counterproposal: this is a one time exception for systemd. Other
packages that wish to do this must specifically ask for exceptions.
19:05:31 <abadger1999> halfline: i'd put consistent with upstream as a
comparatively low priority in general.
19:05:48 <mmaslano> +1
19:05:53 <mitr> halfline: Such projects already must have a configuration variables
that decide between /bin /usr/bin etc., so it seems trivial to have a variable that
switches between /lib and /usr/share
19:05:53 <mjg59> mitr: How does the existing systemd behaviour contravene the FHS?
19:06:02 <mmaslano> um +1 to mitrs proposal
19:06:11 <abadger1999> halfline: for instance, things that are multilib would need
to modify their locations at a higher priority than what upstream wants.
19:06:14 <sgallagh> nirik: I think FESCo exceptions are assumed to be possible no
matter what
19:06:15 <t8m> nirik, we don't need to vote on this - this is just what is
agreed upon by FPC
19:06:19 <mitr> mjg59: See abadger1999's descriptions of %{_datadir} and various
others above
19:06:21 <sgallagh> I'm fine with mitr's phrasing. +1
19:06:39 <mjg59> mitr: Those appear to be descriptions of Fedora policy, not the
FHS
19:06:56 <nirik> sure, then I am confused why we are not done with this ticket? :)
why do we need anything else...
19:07:11 <notting> mjg59: using /usr/lib instead of /usr/lib<qual> could be
argued to contravene it
19:07:18 <mitr> mjg59: Using %{_datadir} for non-archspecific is one of the
cornerstones of FHS.
19:07:29 <nirik> I mean, proposal: packages entering the fedora collection should
meet fedora packaging guidelines. Does that get us anywhere? ;)
19:07:33 <t8m> nirik, we have the mitr's proposal for statement of future FESCo
intention
19:07:36 <sgallagh> Proposal: move on to the next topic :)
19:08:02 <mjg59> notting: The presence of lib<qual> is optional, so it'd
be invalid for any application to depend upon it. Distribution policy may require its use,
but I don't think that's an FHS constraint.
19:08:03 <nirik> sgallagh: +1
19:08:11 <t8m> we are not finished voting - I see +4 on mitr's proposal
19:08:13 <mjg59> mitr: No, that's not actually something the FHS says
19:08:29 <mitr> mjg59:
http://www.linuxbase.org/betaspecs/fhs/fhs.html#thefilesystem
19:08:45 <mjg59> mitr: Yes, I know
19:08:56 <nirik> -1 to mitr's proposal, because I think it's
unneeded/confusing.
19:09:40 <t8m> notting, abadger1999, ?
19:09:54 <notting> nirik: believe i was already -1
19:09:55 * abadger1999 votes with nirik on this
19:10:10 <t8m> OK then, moving on
19:10:37 <t8m> #topic Next meeting chair
19:10:47 <t8m> When we will meet next?
19:11:01 * mitr won't be available on Dec 26
19:11:10 * t8m neither
19:11:15 <mmaslano> in January?
19:11:17 * notting neither
19:11:30 <mmaslano> 2nd January?
19:11:39 * abadger1999 won't be available Dec 26, Probably not on Jan 2 either
19:12:18 <t8m> Anybody else won't be able to join the meeting on Jan 2?
19:12:27 * nirik should be around then, but also won't cry if we don't meet. ;)
19:12:44 <notting> i should be around on the 2nd
19:12:52 <t8m> I am not sure if I'll be around on 2nd or not
19:13:14 <mmaslano> so 9th January
19:13:20 <sgallagh> I will most probably be around the 2nd
19:13:48 <mitr> I'll probably be available on the 2nd
19:14:08 <mmaslano> do we have a quorum for 2nd?
19:14:13 <mmaslano> I can attend
19:14:20 <t8m> I think we can try to meet on 2nd - we'll see if the quorum will
appear
19:14:31 <mmaslano> ok
19:14:53 * sgallagh volunteers to chair on the 9th
19:15:01 <t8m> #info Next FESCO meeting will be on Jan 2nd 2013
19:15:09 <mmaslano> I can chair 2nd January
19:15:31 <t8m> #action mmaslano will chair on 2nd January meeting
19:16:03 <t8m> #action sgallagh will chair on 9th January meeting
19:16:15 <t8m> #topic Open Floor
19:16:25 <t8m> Anybody has anything for open floor?
19:17:59 <t8m> If not I close the meeting in 2 minutes.
19:19:25 <t8m> #endmeeting
4:56 p.m.
New subject: 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
7:54 p.m.
New subject: 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 | mjg59(a)srcf.ucam.org
8:28 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, Dec 20, 2012 at 01:54:57AM +0000, 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
2:02 p.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, Dec 20, 2012 at 02:28:48PM +0000, Richard W.M. Jones wrote:
On Thu, Dec 20, 2012 at 01:54:57AM +0000, 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
4:30 p.m.
New subject: 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/
5:27 p.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, Dec 20, 2012 at 10:30:37PM +0000, 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 | mjg59(a)srcf.ucam.org
10:38 p.m.
New subject: 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 +0000, 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
10:54 p.m.
New subject: 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 | mjg59(a)srcf.ucam.org
11:09 p.m.
New subject: 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
11:16 p.m.
New subject: 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
12:01 a.m.
New subject: 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
7:31 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, 21.12.12 07:01, Ralf Corsepius (rc040203(a)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.
11:30 a.m.
New subject: 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 ☁☁☁ <mattdm(a)fedoraproject.org>
12:33 p.m.
New subject: 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
1:19 p.m.
New subject: 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
12:25 p.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On 20 December 2012 22:16, Adam Williamson <awilliam(a)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
11:36 p.m.
New subject: 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 | mjg59(a)srcf.ucam.org
12:16 a.m.
New subject: 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
12:30 a.m.
New subject: 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 | mjg59(a)srcf.ucam.org
9:49 a.m.
New subject: 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...
10:22 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
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...
How do you manage to do anything on Ubuntu?
--
Matthew Garrett | mjg59(a)srcf.ucam.org
10:37 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 04:22:47PM +0000, 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/
10:55 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 04:37:59PM +0000, Richard W.M. Jones wrote:
On Fri, Dec 21, 2012 at 04:22:47PM +0000, 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 | mjg59(a)srcf.ucam.org
10:59 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 04:55:09PM +0000, Matthew Garrett wrote:
On Fri, Dec 21, 2012 at 04:37:59PM +0000, Richard W.M. Jones wrote:
> On Fri, Dec 21, 2012 at 04:22:47PM +0000, 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 :|
11:58 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 04:59:59PM +0000, 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 | mjg59(a)srcf.ucam.org
11:09 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 04:55:09PM +0000, Matthew Garrett wrote:
On Fri, Dec 21, 2012 at 04:37:59PM +0000, Richard W.M. Jones wrote:
> On Fri, Dec 21, 2012 at 04:22:47PM +0000, 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
11:13 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 05:09:00PM +0000, Richard W.M. Jones wrote:
On Fri, Dec 21, 2012 at 04:55:09PM +0000, 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 | mjg59(a)srcf.ucam.org
11:18 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 05:13:17PM +0000, Matthew Garrett wrote:
On Fri, Dec 21, 2012 at 05:09:00PM +0000, Richard W.M. Jones wrote:
> On Fri, Dec 21, 2012 at 04:55:09PM +0000, 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 :|
7:24 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, 21.12.12 05:38, Ralf Corsepius (rc040203(a)freenet.de) wrote:
On 12/21/2012 12:27 AM, Matthew Garrett wrote:
>On Thu, Dec 20, 2012 at 10:30:37PM +0000, 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.
8:17 a.m.
New subject: 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 (rc040203(a)freenet.de) wrote:
> On 12/21/2012 12:27 AM, Matthew Garrett wrote:
>> On Thu, Dec 20, 2012 at 10:30:37PM +0000, 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
12:38 p.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, 2012-12-21 at 15:17 +0100, Ralf Corsepius wrote:
> 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.
If everyone who implements a standard adapts it to their 'requirements'
and 'demands', then how is it a standard exactly?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
2:24 a.m.
New subject: 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 +0000, 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
2:34 a.m.
New subject: 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 +0000, 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
6:05 p.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Dec 20, 2012 3:16 PM, "Richard W.M. Jones" <rjones(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
6:15 p.m.
New subject: 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 ☁☁☁ <mattdm(a)fedoraproject.org>
11 p.m.
New subject: 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
6:18 p.m.
New subject: 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"
<rjones(a)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 | mjg59(a)srcf.ucam.org
8:05 p.m.
New subject: systemd unit file location
On 12/20/2012 03:30 PM, Richard W.M. Jones 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).
Shouldn't they be in /usr/share/systemd?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
8:35 p.m.
New subject: systemd unit file location
On Thu, Dec 20, 2012 at 07:05:52PM -0700, Orion Poplawski wrote:
Shouldn't they be in /usr/share/systemd?
The helper binaries? No. The unit files? They need to be in / rather
than /usr, which obviously isn't a problem for Fedora but would be on
some other distributions.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
6:06 p.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, 20.12.12 12:02, Toshio Kuratomi (a.badger(a)gmail.com) wrote:
On Thu, Dec 20, 2012 at 02:28:48PM +0000, Richard W.M. Jones wrote:
> On Thu, Dec 20, 2012 at 01:54:57AM +0000, 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.
7:50 p.m.
New subject: 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.badger(a)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
8:07 p.m.
New subject: 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
8:48 p.m.
New subject: 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
8:54 p.m.
New subject: 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
9:05 p.m.
New subject: 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
9:10 p.m.
New subject: 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
9:57 p.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, 20 Dec 2012 19:10:45 -0800
Adam Williamson <awilliam(a)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
11:06 p.m.
New subject: 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 | mjg59(a)srcf.ucam.org
7:04 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, 21.12.12 05:06, Matthew Garrett (mjg59(a)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.
7:36 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
Lennart Poettering <mzerqung(a)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.amundsen(a)usit.uio.no>
Center for Information Technology Services, University of Oslo
9:18 p.m.
New subject: 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 ☁☁☁ <mattdm(a)fedoraproject.org>
9:22 p.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 4:05 AM, Adam Williamson <awilliam(a)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
9:30 p.m.
New subject: 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
<awilliam(a)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
10:01 p.m.
New subject: 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
10:30 p.m.
New subject: 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
1:24 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
-Toshio
On Dec 20, 2012 7:05 PM, "Adam Williamson" <awilliam(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
1:39 a.m.
New subject: 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
2:44 a.m.
New subject: 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
1:45 a.m.
New subject: 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 | mjg59(a)srcf.ucam.org
2:42 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 07:45:45AM +0000, 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
4:26 a.m.
New subject: 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 +0000, 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
10:47 a.m.
New subject: 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 | mjg59(a)srcf.ucam.org
12:36 p.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 04:47:58PM +0000, 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
7:37 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, 20.12.12 23:24, Toshio Kuratomi (a.badger(a)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.
1:17 p.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
Lennart Poettering (mzerqung(a)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
1:26 p.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
Once upon a time, Bill Nottingham <notting(a)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 <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
1:46 p.m.
New subject: 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 (mzerqung(a)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
8:11 a.m.
New subject: 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/
9:12 p.m.
New subject: 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 ☁☁☁ <mattdm(a)fedoraproject.org>
7:15 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, 20.12.12 18:48, Toshio Kuratomi (a.badger(a)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.
8:41 p.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 1:06 AM, Lennart Poettering
<mzerqung(a)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
11:35 a.m.
New subject: 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
12:46 p.m.
New subject: 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
10:10 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Wed, Dec 19, 2012 at 11:56 PM, Kevin Kofler <kevin.kofler(a)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
12:47 p.m.
New subject: 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
4141
days inactive
4146
days old
76 comments
21 participants
participants (21)
-
Adam Williamson -
Bill Nottingham -
Chris Adams -
Daniel P. Berrange -
Don Dutile -
Florian Weimer -
Kevin Fenzi -
Kevin Kofler -
Lennart Poettering -
Matthew Garrett -
Matthew Miller -
Miloslav Trmač -
Nicolas Mailhot -
Orion Poplawski -
Paul Wouters -
Ralf Corsepius -
Richard W.M. Jones -
Stephen John Smoogen -
Tomas Mraz -
Toshio Kuratomi -
Trond Hasle Amundsen