17:00:54 #startmeeting Fedora Packaging Committee 17:00:54 Meeting started Wed Mar 7 17:00:54 2012 UTC. The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:54 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:57 #meetingname fpc 17:00:57 The meeting name has been set to 'fpc' 17:01:01 #topic Roll Call 17:01:15 I'm here, but terribly distracted at the moment. 17:02:21 * spot suspects abadger1999 is doing pycon related things today 17:02:54 * limburgher here, have to run for coffee, back in like 2 min. 17:03:24 * SmootherFrOgZ wille be around in a couple of minutes :/ 17:03:29 will* 17:05:00 hola 17:05:12 * rdieter coffee's up too 17:05:28 * spot is waiting for everyone to come back with coffee 17:06:21 * geppetto is here 17:06:31 * limburgher coffee'd 17:06:34 * geppetto has tea 17:07:00 okay, i see +6, give or take a coffee 17:07:01 nom 17:07:16 * racor is half here and will likely be disrupted+distracted, soon 17:07:26 #topic Forks - https://fedorahosted.org/fpc/ticket/148 17:07:48 racor: Transporter accident? 17:07:56 I'm not sure there is anything we need to do here, to be honest. We have rules about Conflicts that cover this sort of thing already. 17:08:47 opt for d. 17:08:49 We do sort of have a fork-discouragement policy as part of the bundled library stuff. 17:08:49 Right. We have multiple packages that do the same thing, some were forks once, some weren't. If they play well together, fine. Think Blackbox/Fluxbox. 17:09:11 limburgher: ?!? 17:09:17 vote for d) 17:09:25 racor: Star Trek. Sorry. :) 17:09:28 But I guess if someone wants to really fork something and do it right (i.e. make a real upstream project for the fork) then that's not our business. 17:09:35 d 17:09:40 limburgher: 'k 17:09:43 +1 for "d" 17:10:01 Besides, we have things with dead/nebulous upstreams that the maintainers do a respectable job on. 17:10:17 +1 d (explicitly, if we're formally voting) 17:10:22 I'm for "d" as well, but I'm just concerned about appearing inconsistent. 17:10:29 +1 for d. 17:11:06 I'm kind of for d … in that I assume the package reviews will weed out those that b is trying to stop, right? 17:11:23 Never assume package reviews will weed out anything. 17:11:31 tibbs|h: :) 17:11:40 It depends entirely on who is doing the review. 17:11:44 geppetto: THough, in a perfect world, yes. 17:11:48 In that case I'd rather explicitly state that you can't just randomly fork something and get it in Fedora. 17:11:50 hi all 17:12:10 as much as i am on the public record hating code which fails case b, i don't want to turn the packaging guidelines into a political document 17:12:14 sorry for being late, I was commuting 17:12:20 geppetto: What would be an example you'd not have us allow? 17:12:21 I mean, assume the github "forks are cheap" model. 17:12:43 Is each of those a separate upstream to be packaged? 17:12:45 if the code doesn't conflict with an existing package and it follows the guidelines, why not? 17:13:06 exactly 17:13:09 Sure. 17:13:16 limburgher: Random person can't get random patch into XYZ … for a laugh says "I've forked it". 17:13:37 Except that we already preach against this strongly if you do the minimum additional work of copying the "fork" into your source tree. 17:13:50 geppetto: Gotcha. 17:14:39 geppetto: person will have to make sure his works properly installs in parallel to the original works ;) 17:14:59 Meh. … I'm mostly happy to be optimistic about it, and vote d. 17:15:03 tibbs|h: and iirc, we have resolved some of those situations by separating the fork into its own separate package. 17:15:05 racor: That's still not a high bar. 17:15:09 racor: That's often enough of a challenge to deter that sort of thing. :) 17:15:26 geppetto: Depends on the package. 17:15:44 True, it does stop glibc forks :) 17:15:49 if geppetto is voting +1 on d, then we'd be at +5 17:16:27 geppetto: do i have that right? :) 17:16:35 yeh, I am … I just reserve the right to do an "I told you so" dance at some point because we didn't do b :) 17:16:45 geppetto: okay. :) 17:17:34 #action The FPC does not see a need for additional guidelines relating to forks at this time, they should be treated like any other package. (+1:5, 0:0, -1:0) 17:18:13 #topic Consider possibility of non-standard service commands in the systemd world - https://fedorahosted.org/fpc/ticket/149 17:18:56 Again, i'm not entirely sure how this is an FPC issue to resolve, it seems more like a bug for the systemd folks to address. 17:19:26 I think the issue is that there's already something that works in this case, except that it violates the packaging guidelines. 17:19:28 I'm of a mind to opt for c here (or agree with spot that it's not our problem domain) 17:19:30 Yeh, I thin kthe _best_ option would be to organize the common "extra" commands and integrate them into systemdctl 17:19:41 Other than that, I guess option c. 17:20:02 tibbs|h: that being basically where "service" falls back to the initscript for any commands not in the default systemctl set? 17:20:08 Exactly. 17:20:23 tibbs|h: the ticket says "After conversion to systemd, these are no longer possible. " or is it? 17:20:35 tibbs|h: That works now? 17:20:38 So you can still ship an "initscript" so that "service iptables save" continues to work. 17:20:46 At least that's what I got out of the discussion. 17:20:48 rdieter: well, it means "these nonstandard options don't work with systemctl" 17:20:55 oh. 17:20:57 Oh … you mean not having a systemted unit file, at all? 17:21:04 No, you have a unit file. 17:21:07 when notting rewrote service to enable it for systemd 17:21:20 I'm ok with the initscript fallbacks then, meh 17:21:38 he coded it so that it would simply redirect the options that systemctl knows about and would try to handle all the others normally 17:21:51 So … yeh, if option a is actually "allow a compat. hack to continue to work" I'm fine with it. 17:21:56 my worry about just allowing the fallbacks is that it isn't an entirely logical workflow. 17:22:12 and there is a good chance people will assume that the initscript is being used all the time 17:22:13 The word "fix" implied that something needed to be written/fixed. 17:22:15 make changes there 17:22:21 I'm also ok with (strongly or otherwise) discouraging the use of such fallbacks 17:22:22 and then get confused as to why they don't take effect 17:22:46 it seems like we really want systemd to have some documented way to add "non-standard" options on a per unit basis 17:22:46 rdieter: Yeh, just "one more thing" that's different from pre-systemd 17:23:02 spot: Yeh, but we can't mandate that. 17:23:08 spot: 17:23:13 no, but we can ask them if they'd be willing to do it 17:23:16 If we could there's a long list of things I'd want systemd to do ;) 17:23:20 Sure. 17:23:21 if they say no, then at least we know that much 17:23:49 so, i propose we table this for a week to give me a chance to talk to lennart/kay 17:24:04 table++ 17:24:12 +1 17:24:22 table+1 17:24:29 Fine with me. 17:24:46 okay, moving on 17:24:56 #topic Scripting inside of spec files - https://fedorahosted.org/fpc/ticket/150 17:25:17 I'm not comfortable with this, honestly. 17:25:32 Yeah, this seems odd. I'm not sure what problem we're solving here. 17:25:44 I do understand and sympathize with the underlying problem. 17:25:52 tibbs|h: which is? 17:26:19 Basically, bootstrapping can get really hard if you can't even build packages because someone decided to use ocaml in the spec. 17:26:39 yes, but we could s|ocaml|anything|g there 17:26:40 I thought it was just random packagers looking at random spec files and seeing ruby code everywhere or something. 17:26:44 So this would make things like porting to new arches easier? 17:26:48 i'm not sure python/perl are safe in that context either 17:26:54 Of course. So they're saying "anything" is restricted to a limited set. 17:26:55 I agree with the draft, frankly. 17:27:18 I'd be happy to mandate python/lua/bash only in specfiles, personally. 17:27:41 And mostly happy to get rid of python too. 17:27:47 geppetto: well, there is a fair bit of existing perl oneliners to do various tasks 17:28:07 Then again, I'm not sure how much difference there really is between having perl in the specfile and calling a perl command from the specfile. 17:28:19 I would be fore this if it was a suggestion with a description of what problems not following the suggestion causes. 17:28:31 But a hard rule isn't something I can get behind. 17:28:39 i'm not opposed to saying "perl or python (if you BuildRequires appropriately), or shell/lua" 17:28:57 * geppetto nods … +1 17:29:10 i just dont want to set off a "why are you hating on ocaml/fortran/brainfuck" war. 17:29:10 Do we have an idea of how many packages, today, all afoul of this? 17:29:15 tibbs|h: IIRC, the OP was stuck in a circular BR:-loop when building on a secondary arch (IIRC, it was the arm). 17:29:17 tibbs|h: you have a point, a proposed guidelines ought to have a justification along with it 17:29:24 Yes, this was during the arm bootstrapping. 17:29:36 Which is still not done, in part because of this problem. 17:30:03 Would this guideline solve that issue? 17:30:05 And the proposal does have a rationale, with which I don't really disagree. 17:30:14 spot: Yeh, we'd probably need to word it like "don't add any buildRequires that upstream doesn't already have" or something. 17:30:22 I think it would solve that issus to some extent. 17:30:26 geppetto: well, it doesn't say that. 17:30:31 Yeh, I know. 17:30:40 It does say that. 17:30:56 See "Additionally, if your package cannot build without a specific scripting language....". 17:31:01 tibbs|h: not really, it says if you call perl or python, BR it. 17:31:12 tibbs|h: doesn't say "only use perl if perl is already a BR" 17:31:39 I interpret the "Additionally..." the same as tibbs|h 17:31:41 It says you can use perl, python, standard stuff or whatever your package happens to need to build anyway. 17:31:48 that "Additionally" just says you can use another scripting language if it's already being pulled in as BR for the code 17:32:21 if the package is python, and the packager wants to add a perl script, this doesn't forbid that as long as there is a BuildRequires: perl 17:32:23 right, did anyone sugggest otherwise? (else, I'm confused) 17:32:56 if we added a "don't add any BR that upstream doesn't already have", we'd be forbidding that usecase 17:33:10 Right. 17:33:21 oh, fwiw, I like the draft as-is, don't muck with it. :) 17:33:31 spot: I was thinking more for the ocaml/ruby case than the python/perl case 17:33:35 rdieter: lua is missing from the draft 17:33:49 what's the justification for adding lua? 17:33:51 as is, i think i'm okay with it, with the addition of lua (since rpm groks lua natively) 17:33:53 bash needs it 17:33:58 it's rpm built-in ;) 17:34:11 We could probably except the couple of packages that need it, but meh. 17:34:15 do lua scripts require extra BR's? 17:34:19 No 17:34:21 rdieter: no 17:34:21 rdieter: nope. 17:34:27 then what's the problem ? 17:34:40 rdieter: we just don't want people to think lua is not allowed 17:34:46 so we want to explicitly call it out as okay 17:34:52 ok 17:34:59 And state why. 17:35:04 yep. 17:35:12 lua++ from me then 17:35:18 so I'm +1 on this with the addition of lua (because lua is native in rpm) 17:35:28 +1 as well 17:35:39 +1 17:36:04 As I stated earlier, -1 if this is anything more than a strong suggestion. 17:36:41 I read the wording as a strong suggestion 17:36:53 "may in general only use the following languages" 17:36:55 +1 17:37:03 * spot does not the wording does not say "MUST" anywhere. 17:37:08 s/not/note 17:37:15 exactly 17:37:16 We don't generally use the guideline "may in general" in the guidelines, do we? 17:37:24 tibbs|h: no, we really don't. 17:37:32 shall we replace that with SHOULD? 17:37:34 we probably need and explicit SHOULD or MUST in there then 17:37:45 i'm okay with replacing that with SHOULD 17:37:49 I assumed when written up this would go to either should or must, and I can't get behind it if must. 17:37:54 If "should", then +1. 17:38:01 * limburgher should write a mediawiki-subjunctivizer plugin 17:38:04 SHOULD it is 17:39:00 sounds like we're up to +6 then, win 17:39:06 * spot posts a new draft in the comment 17:39:52 https://fedorahosted.org/fpc/ticket/150#comment:1 17:39:57 +1, however I dislike the SHOULDS because they tend to introduce room for discussions 17:40:29 okay, so i think we're at +7 here. 17:40:46 #action Worded as a SHOULD, this is approved. (+1:7, 0:0, -1:0) 17:41:16 #topic Add link to tmpfiles.d - https://fedorahosted.org/fpc/ticket/151 17:41:26 this is an easyfix, i see no reason why we should not simply do this 17:41:46 just do it +1 17:41:48 +1 17:41:56 +1 do it. 17:42:07 We shouldn't have to vote on anything that makes the guidelines easier for folks to navigate. 17:42:16 +1 17:42:26 #action EASYFIX, just do it. 17:42:36 yup 17:42:38 #topic /etc/default vs /etc/sysconfig - https://fedorahosted.org/fpc/ticket/152 17:43:21 FWIW, i don't think telling upstreams that they must put files in /etc/sysconfig instead of /etc/default is an approach that will bear much fruit. 17:43:26 I at first thought: oh ick, but spot's symlink suggestion seems to minimize the ick for me 17:43:49 spot: Yeh, but we can say "no Fedora package will have files in /etc/default" 17:43:53 if we just make the symlink to /etc/sysconfig, then if you don't know about /etc/default, then all is fine. 17:44:06 If you're looking at upstream docs which reference /etc/default, all is fine. 17:44:07 spot: The symlink thing would be fine, if there weren't already packages that created that dir. … or rpm could convert. 17:44:13 I meant upstream should use directly /etc, not /etc/default. /etc/sysconfig is for distros. /etc is for upstream configs. Why to use /etc/default upstream? 17:44:31 geppetto: it would only affect packages that owned /etc/default, right? 17:44:33 spot: I think jan had a real point in comment#9 17:44:43 I like the symlink. I think /etc/default is silly, but someone could file an upstream bug. 17:45:01 jankratochvil: /etc/default is debian/ubuntu's /etc/sysconfig 17:45:10 spot: Grub puts files in /etc/defualt now … so how do we create the symlink? 17:45:15 i don't believe either is in FHS 17:45:27 I don't think we can change this now for the packages that do use /etc/default. 17:45:28 spot: Yes, then it is irrelvant for upstream. 17:45:55 It can be considered only as a future direction. 17:45:57 jankratochvil: yes, so we can spend time telling upstream that the thing that just works for the platform that they care about "ubuntu" is a bug 17:46:06 or we can simply make the symlink and let it go. :) 17:46:10 I'm against symlinking if we can avoid it, it's always a mess to deal with at rpm level 17:46:22 spot: and fight with file conflicts ... 17:47:00 spot: It's like one package? … it's not like we have to argue with 666 upstreams 17:47:04 spot: [flame] We could live with many bugs.Ubuntu has. 17:47:18 I'm +1 on banning it. 17:47:38 racor: what file conflicts? 17:47:47 racor: we're not symlinking the files, just the top-level dir 17:47:49 It is now also glibc (I did not investigate more) and shadow-utils. 17:48:22 glibc-common owns /etc/default/nss, shadow-utils /etc/default/user-add 17:48:23 spot: let ubuntu invent a /etc/defaults/network ... 17:48:44 racor: ah, well, that is a hypothetical scenario i suppose 17:48:51 how about we solve problems when/if they happen ? 17:48:53 we'd have the same problem if they standardized on something in /etc 17:49:27 it's not an either or that we symlink *and* discourage the use of /etc/default at all 17:49:27 Surely someone can speak to the glibc people and tell them to pick a better dir. 17:49:39 It's not like they should be a hostile upstream or anything 17:49:40 we can surely do both 17:49:48 spot: Sure, all contents of /etc/sysconfig is proprietary/vendor-specific. If you symlink you give room for all kind of clashes. 17:49:51 that glibc is some mistake, I was filing it originally for grub2. 17:49:53 geppetto: surely, you did not just volunteer to take that up with uli. ;) 17:50:03 In fact tell them to use sysconfig upstream … and let Debian/Ubuntu fight it out upstream ;) 17:50:15 meh, why won't glibc use /etc/glibc? 17:50:26 I consider it as if Fedora has /etc/default/ it means Fedora has started to be a fork of Debian. 17:50:27 or just /etc 17:50:37 * rdieter likes /etc/bikeshed 17:50:46 jankratochvil: that's a bit hyperbolic. 17:50:55 * Rathann throws a bucket of blue paint on it 17:51:17 grub2/glibc/shadow-utils should just use /etc, that is a dir for config files. There is no need to have any subdirectory there. 17:51:26 I still propose that we symlink for convenience and strongly discourage packages from using /etc/default 17:51:38 -1 on symlink 17:51:40 spot: +1 17:51:42 actually I'd support just banning it 17:51:57 symlink is a workaround of packaging bug, BTW I would fish I have never filed it if it ends up as a symlink. 17:52:02 -1 on symlink, +1 on jankratochvil 17:52:30 racor: what exactly is jankratochvil's proposal? that we ban /etc/default outright? 17:52:58 spot: plain /etc for glibc, grub2 etc. 17:53:25 I would see it not as ban but discourage, it is probably better to keep /etc/default/ if upstream keeps it but it is best to convince upstream to /etc/default/ -> /etc/ . 17:53:54 * rdieter notes spot's proposal did include discouraging /etc/default already 17:53:58 Or /etc/default => /etc/glibc … or whatever. 17:54:22 /etc/glibc does not seem to work for me. 17:54:28 * spot just doesn't see the point of breaking upstream docs when they won't convert. 17:54:35 * rdieter either 17:54:37 * jankratochvil agrees with spot 17:54:52 s/when/if/ they won't convert 17:55:00 I could live with "discourage it" but allow it 17:55:06 so we need the symlink for that to work. hell, we can symlink it to /etc if that is a more reasonable namespace 17:55:38 symlink would hide that upstream has it broken. 17:55:42 the core of this bug seems to be "we dont want files in yet-another-directory under /etc" 17:55:44 But personally I think "default" is a terrible name 17:56:03 jankratochvil: i'm not sure we can make the argument that default is anymore "broken" than sysconfig 17:56:21 sysconfig is also broken for upstream package. 17:56:25 and i really don't think we're about to say that /etc/sysconfig is forbidden 17:56:34 jankratochvil: but some of them use it 17:56:45 That grub2 is a bit special case IMO, boot loader is very distro specific thing se there could be /etc/sysconfig/ tolerable. 17:57:15 spot: There is no /etc/sysconfig on my Ubuntu box here. 17:57:19 upstream packages have many bugs, Fedora fixes them and pushes back upstream. 17:57:38 jankratochvil: i'm not sure how this could be considered a bug. 17:57:44 the FHS doesn't forbid use of /etc/default 17:58:19 if the bug is "people can't find the config file because they don't expect to look there on Fedora" 17:58:22 then we fix _that_ bug 17:58:30 Then Debian has to start using /etc/default2/ as it conflicts with various upstream packages. This won'\t happen. 17:58:41 jankratochvil: let Debian worry about its bugs. 17:58:55 If the bug is is a dumb name, we say "yes, yes it is, but. . ." 18:00:45 * spot is willing to consider alternate proposals, but right now, i only see mine, and i'm not entirely sure what jankratochvil is proposing. 18:01:23 I was more expecting some recommendation here from packagers, 18:01:27 not everyone voted on spot's proposal, yet, afaict 18:01:47 originally I only targeted grub2 which is very distro-installation-specific thing so I thought it can be changed arbitrarily downstream in Fedora, 18:01:58 it turned out we solve larger problem for more packages. 18:02:31 jankratochvil: googling implies that /etc/default is the "default" for debian, ubuntu, arch, opensuse, and fedora 18:02:38 at least in the grub2 case 18:03:08 spot: "default" for what? 18:03:16 "default" does not make sense. 18:03:29 For where grub2 drops things, I assume. 18:03:31 it is where they have their grub2 package storing config files 18:03:58 so for us to say this is some sort of distribution independent bug seems... unfounded. 18:04:13 geppetto: default implies there would be some sort of search order, say /etc:/etc/default 18:04:22 That glibc and shadow-utils /etc/default/{nss,useradd} are already in RHEL-5, I did not notice it is so old. (/etc/default/nss is in upstream glibc since 2004). 18:04:26 if anything, if we force the Fedora packages to stop doing this, we'll be differing for no valid technical reason. 18:05:27 I see it is nothing new, I did not notice /etc/default/ exists upstream for so long, it is just now more visible with grub2. 18:05:31 racor: Yeh, that's why I think it's a terrible name … 18:05:33 So, we can either make these files easier to find with a directory symlink (either to /etc/sysconfig or to /etc), or we can simply do nothing and assume that people can find it. 18:06:01 I just don't see the logic in diverging from upstream here. 18:06:13 Of the three proposals: 1) bann it. 2) Create symlink. 3) ignore it. … I'm: +1 -1 +1 18:06:27 if someone wanted to convince these upstreams to move, then, that's fine, and we'd naturally inherit that. 18:06:57 spot: I see one: telling upstreams their conventions aren't helpful 18:07:03 Of geppetto's three proposals, i'm -1, +1, +1 18:07:13 +1 ban, -1 symlink 18:07:28 racor: What about just ignore it? 18:07:32 racor: they aren't harmful either. 18:08:36 -1 ban, +1 symlink, +1 ignore 18:09:04 * rdieter agreeing with spot's rationale 18:09:14 -1 ban +1 symlink 0 ignore. I think if someone wants to champion getting upstream to change, they should. 18:09:21 spot, geppetto: I don't have a strong opinion on ignoring, but I feel it's our job to implement rules for "best practices" 18:09:27 +1 ban, -1 symlink, +1 ignore 18:09:46 Ok, looks like ignore has it … resolved! 18:10:01 we don't have +5 on ignore yet, i don't believe. 18:10:13 tibbs|h: Ignore? 18:10:38 i see +1 +1 0 +1 0 +1 18:10:43 I am heavily distracted right now, but I'm finding it tough to get behind anything, really. 18:10:56 Which does sort of skew towards "ignore". 18:11:28 But that doesn't mean that I don't see it as an issue that would have been nice to avoid somehow. 18:12:19 SmootherFrOgZ: if you're here, you can also vote. 18:13:21 I am fine with "ignore" now after the discussion, thanks. 18:14:14 tibbs|h: any chance you could just vote so we can close it out for now? 18:14:17 :) :) :) 18:14:22 +1 ignore 18:14:22 +1 18:14:23 sorry 18:14:32 no problem 18:14:54 #action Just ignore this issue, let people talk to upstreams if they are motivated to do so. (+1:5, 0:2, -1:0) 18:15:27 and with that, i think we're done for today. we'll pick up #153 next week 18:15:35 #topic Open Floor 18:16:12 spot: Which packages are allowed to use /etc/default? I guess, we just shifted Fedora into a position of "iif Debian does so". 18:16:51 racor: more like "iff upstream does so" 18:17:03 I filed it originally as I consider grub2 (or grub or lilo or anything like that) very distro specific thing but I see now it is more used as is from upstream so it is more an issue to discuss upstream than in Fedora. 18:18:18 i don't believe any of the instances noted are places where the Fedora package is using /etc/default as an override, but rather, that is where upstream places these files (and assumes they are present) 18:19:11 okay, thanks guys. 18:19:13 #endmeeting