===================================
#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