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