17:01:44 <spot> #startmeeting Fedora Packaging Committee
17:01:44 <zodbot> Meeting started Wed Mar 21 17:01:44 2012 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:44 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:49 <spot> #meetingname fpc
17:01:49 <zodbot> The meeting name has been set to 'fpc'
17:01:53 * abadger1999 here
17:01:53 <spot> #topic Roll Call
17:02:06 <spot> brb, need to refill my drink
17:04:02 * geppetto is here
17:04:22 * SmootherFrOgZ here
17:04:59 <spot> racor, tibbs|h: ping?
17:05:15 <tibbs|h> Howdy.
17:05:30 <rdieter> hi
17:05:38 <tibbs|h> Not sure how long I can stay.
17:06:25 <spot> okay, well, we've got quorum
17:06:34 <spot> so lets get through as much as we can. :)
17:06:49 <spot> #topic Non standard service commands in the systemd world - https://fedorahosted.org/fpc/ticket/149
17:06:56 <spot> I spoke to Kay on this
17:07:20 <spot> and the systemd stance is basically "apps should provide their own scripts to perform these non standard commands"
17:07:33 <spot> systemctl is never going to have support for calling these commands natively
17:08:24 * racor is here, was distracted on the phone, sorry
17:08:46 <abadger1999> A lot of apps have survived just fine with pushing the non-standard commands to their own scripts.
17:08:55 <spot> So, our remaining options are: Allow packages to carry the sysvinit script in addition to the unit file when non-standard commands are in use, OR Advise packagers to convert the non-standard commands to helper scripts (e.g. iptables-restore)
17:09:16 <tibbs|h> Well, the latter is going to have to happen anyway.
17:09:18 <spot> Of the two, I prefer the latter.
17:09:29 * abadger1999 prefers the latter as well.
17:09:38 <tibbs|h> Whether we still allow a stub sysvinit script to call those helper scripts is really the question here.
17:09:40 <geppetto> yeh, systemctl + sysv just feels like pain
17:10:09 <spot> tibbs|h: i think the answer is no. i just don't like keeping even a stub around.
17:10:36 <spot> i think that's asking for confusion.
17:11:28 <tibbs|h> I personally don't have a problem with allowing the stub for the sake of the users.  But it should be absolutely forbidden for the initscript to be the only way to get that stuff.
17:11:51 <tibbs|h> Actually I think that should have been forbidden long ago, well before systemd.
17:12:07 <abadger1999> <nod>
17:13:08 <spot> So, I propose adding the following wording: "Packages which have SysV initscripts that contain 'non-standard service commands' (commands besides start, stop, reload, restart, or try-restart) must convert those commands into standalone helper scripts. Systemd does not support non-standard unit commands."
17:13:21 * abadger1999 still prefers no stub... could see a stub that just returns "The new way to do this is /usr/bin/iptables-restore" to wean people off but... I live in fear of the testing matrix for possible systemd and sysv interactions.
17:13:39 <abadger1999> spot: +1 to your proposal
17:13:50 <rdieter> +1 proposal
17:14:07 <tibbs|h> +1 to spots proposal, and I won't stand in the way of banning stubs if others are onboard with it.
17:14:08 <SmootherFrOgZ> +1
17:14:11 * spot is +1
17:14:14 <racor> +1
17:14:24 <geppetto> +1
17:14:54 <spot> #action Conversion wording approved (+1:7, 0:0, -1:0)
17:15:55 <spot> okay, unless there is a strong push to explicitly ban stubs, lets just move on
17:16:16 <abadger1999> oh, this doesn't ban stubs?
17:16:26 * abadger1999 wonders if it answers the question in the ticket, then
17:16:34 * abadger1999 reads ticket again
17:16:38 <spot> abadger1999: technically, one could still make the stub in a subpackage
17:16:55 <spot> but it wouldn't be permitted in the base package
17:17:07 <tibbs|h> Indeed.
17:17:17 <tibbs|h> That restriction does make it kind of pointless.
17:17:34 <abadger1999> yeah.
17:18:22 <spot> nirik: do you understand what we're saying here? i'd be happy to explain this to FESCo if needed, since this ticket came from there.
17:18:39 * nirik reads back
17:18:41 <abadger1999> nirik: Would a vote on banning stubs (option b in https://fedorahosted.org/fpc/ticket/149 ) be desirable to you?
17:19:38 <spot> because right now, that option b isn't permitted in the guidelines, except if the init script is in an optional subpackage
17:19:47 <nirik> right, so the question I think was "can we have a way to do stubs that tell people to use the new script"
17:19:58 <nirik> but it sounds like you think thats a bad idea and we shouldn't try that...
17:20:39 * rdieter wouldn't mind stubs that do nothing but print text, mostly harmless
17:21:08 <spot> nirik: the only way i can think of doing that is basically option a, where service is patched to respond to all non-standard commands with something like "Systemd no longer supports non-standard commands. Check for $service-$command ?"
17:21:28 <spot> that _should_ not be too hard, but isn't up to the FPC to handle
17:21:50 <nirik> yeah. Although then it would be nice if there was a standard place for them... but not sure thats doable either.
17:21:59 <spot> well, again, hypothetically
17:22:07 <spot> we could specify a namespace standardization here
17:22:23 <spot> iptables-restore being the script version of "service iptables restore"
17:22:24 <tibbs|h> There really aren't that many of these nonstandard commands, are there?
17:22:39 <nirik> partly it's also somewhat moot as we haven't allowed any stubs before, and have had a release without them.
17:22:49 <spot> then have service just handoff non-standard reqs to that namespace
17:23:02 <tibbs|h> The only big ones I can think of are in httpd and iptables.
17:23:23 <spot> service is a big pile of shell anyways
17:23:26 <spot> it should be doable.
17:23:27 <nirik> spot: well, iptables-restore is a different command. ;) The new replacement is: "/usr/libexec/iptables.init restore' or whatever
17:23:31 <geppetto> postgres was the other named example
17:23:47 <spot> nirik: see, thats the biggest problem, standardizing it
17:23:51 <nirik> yeah.
17:24:03 <abadger1999> tibbs|h: postgres had one but tom lane was fine with just creating the script
17:24:11 <abadger1999> probably mysql was similar
17:24:14 <tibbs|h> Actually standardizing it is easy if "service" just handles one thing.
17:24:47 <tibbs|h> So fix "service" to look for "/usr/bin/$service-$command" and everything sort of falls out of that.
17:25:39 <tibbs|h> Wow, /sbin/service has some weird crap in it.
17:25:42 <spot> yeah. if that were to happen, we could amend the approved wording to add "standalone helper scripts using the naming "$service-$command"
17:26:14 <spot> nirik: you probably want to talk to notting about that
17:26:19 <nirik> /sbin/iptables-restore != "/usr/libexec/iptables.init restore" tho.
17:26:26 <spot> but aside from that, i think the fpc answer is "no"
17:26:30 <nirik> but sure, we could ask for some enhancement there.
17:27:10 <spot> okay. moving onward
17:27:23 <spot> #topic EnvironmentFile in /etc/sysconfig only? https://fedorahosted.org/fpc/ticket/153
17:27:52 <tibbs|h> Almost forgot about that one.
17:28:14 <spot> without stepping in a holy war, i think the answer is "no. /etc/sysconfig is preferred, but not required."
17:28:49 <tibbs|h> That's pretty much the status quo, isn't it?
17:28:56 * spot nods
17:29:23 <tibbs|h> But the guidelines explicitly say "Support for /etc/sysconfig files", leading to confusion.
17:29:23 <geppetto> yeh, probably
17:29:42 <geppetto> I'm not really against making the should a must
17:29:53 <geppetto> does anyone have an example that fails?
17:30:00 <abadger1999> It sounds like the example package you've run into is trying to step around what's written in the guideline, though...
17:30:19 <abadger1999> It seems like the intent is "EnvironmentFiles is only to be used for legacy purposes.  Here's how"
17:30:34 <spot> eh, i think that might be a bit extreme
17:30:35 <abadger1999> and in this package it sounds like we have a non-legacy use.
17:30:38 <spot> i know lennart feels that way
17:30:39 <tibbs|h> This came up in a real-world situation.  Someone was doing a systemd conversion (of varnish, I think) and came up with the usage I stated in the ticket.
17:30:42 <abadger1999> <nod>
17:30:50 <abadger1999> And lennart wrote that section, right?
17:30:54 <spot> but i think there are a lot of valid scenarios where having an external config file makes sense
17:30:57 <spot> abadger1999: indeed
17:31:00 <abadger1999> So if we want to allow it... I think we should rewrite that.
17:31:11 <spot> I think we might be able to simply amend it with something like:
17:31:15 <tibbs|h> Yes, it was varnish.
17:31:41 <spot> "While the examples in this section use /etc/sysconfig pathing, other locations under /etc are acceptable for EnvironmentFiles, although, generally discouraged."
17:31:48 <abadger1999> We could remove the last paragraph.
17:31:53 <tibbs|h> And the current package is using /etc/varnish/varnish.params
17:32:20 <rdieter> spot: +1
17:32:36 <rdieter> I can't imagine being overly strict here helps anyone
17:33:02 <tibbs|h> It certainly helps people trying to figure out how to configure things.
17:33:23 <abadger1999> I think I'd rather remove/modify the last paragraph... this seems like config that we'd put into /etc/sysconfig normally.
17:33:36 <tibbs|h> It could be "look for /etc/sysconfig/$foo", now it's "find the .service file for $foo, look for EnvironmentFile, and look in there".
17:33:52 <rdieter> ok, there's that
17:33:52 <abadger1999> so if we want to allow the maintainer to do that, we should just remove the strong suggestion not to use /etc/sysconfig for new files
17:34:12 <spot> tibbs|h: i could see a scenario where the actual daemon config was used for both the service init and the daemon
17:34:33 <spot> although, that may not be likely (or existant)
17:34:37 <rdieter> I guess we're back to encourage use of /etc/sysconfig, but not require it
17:34:44 <tibbs|h> abadger1999: That's the other thing.  We say "don't use /etc/sysconfig for new files" and so people think they just have to put them somewhere else.
17:34:55 <abadger1999> Is this the only section that deals with /etc/sysconfig?  /me is looking to make sure this is the only place that needs modification
17:35:21 <spot> abadger1999: its the only bit in the systemd guidelines
17:35:41 <spot> there isn't anything in the main guidelines
17:36:36 <limburgher> Sorry I'm late.
17:36:42 <limburgher> Where are we?
17:36:52 <tibbs|h> spot: I actually had a package with that usage (daemon config used for both service init and the daemon).
17:37:19 <spot> tibbs|h: okay, so in that case, forcing it to /etc/sysconfig would likely require either symlinking or patching
17:37:21 <tibbs|h> But that usage was undeniably stupid so I got rid of it.
17:37:28 <tibbs|h> By patching.
17:37:32 <spot> but yeah, i agree, thats a bad idea
17:38:02 <abadger1999> How about changing the last paragraph to read "Although /etc/sysconfig files are easy to use, upstream systemd recommends a different approach.  The recommended way for administrators to reconfigure systemd .service files is to copy them from /lib/systemd/system to /etc/systemd/system and modify them there. Unit files in /etc/systemd/system override those in /lib/systemd/system if they otherwise carry the same name.  Both approaches are
17:38:03 <abadger1999> valid in Fedora."
17:38:24 * abadger1999 wonders if he can work something in about outside of /etc/sysconfig is also okay...
17:38:34 <spot> abadger1999: i'm fine with that wording, but it doesn't clarify the original question
17:39:07 <spot> i suppose we could mandate that EnvironmentFiles must be in /etc/sysconfig
17:39:19 <abadger1999> Okay, I've got some rewrites, let me edit, and paste.
17:39:35 <tibbs|h> spot: That's what I thought was the current case.
17:39:50 <tibbs|h> It is certainly strongly implied.
17:39:55 <spot> tibbs|h: i think that is certainly what lennart would want
17:40:28 <tibbs|h> To remove the implication, just talk about "environment files" instead of "/etc/sysconfig files".
17:41:10 <spot> tibbs|h: yeah, that seems simple enough, combined with abadger's wording change for the last paragraph
17:41:32 <abadger1999> this will take me a few minutes.
17:42:02 <spot> okay, while abadger1999 is on that one
17:42:16 <spot> i think we can answer 156 quickly
17:42:30 <spot> 156 is the "tarball download requires a login/password"
17:43:00 <spot> i think the answer is "as long as the license is okay, just explain the lack of upstream URL in a comment."
17:43:15 <rdieter> +1
17:43:22 <geppetto> +1
17:43:28 <SmootherFrOgZ> +1
17:43:34 <spot> +1
17:43:38 <tibbs|h> +1
17:44:18 <tibbs|h> However, this opens up the question of what happens when the requirement is even more onerous.  But I know of only one example of that.
17:44:23 <racor> +1, + adding account and password in clear text in a comment
17:46:24 <spot> okay, while we're on a roll, 155 should be easy as well
17:46:38 <limburgher> +1
17:47:17 <tibbs|h> Wow, I thought factor was something else.
17:47:17 <limburgher> That was for 156.
17:47:20 <spot> #action As long as the license is okay, just explain the lack of upstream URL in a spec file comment. (+1:6, 0:0, -1:0)
17:47:29 <spot> limburgher: yep, got it on the 155 vote.
17:47:33 <limburgher> I think that's facter.
17:48:15 <abadger1999> +1
17:48:27 * abadger1999 has wording for systemd revision now
17:48:28 <abadger1999> https://fedoraproject.org/wiki/User:Toshio/SystemdEnvFiles
17:48:35 <spot> oh, the tasteless jokes. anyways, this seems to clearly meet the compiler bootstrap exception.
17:48:45 <tibbs|h> +1 to 156.
17:48:48 <geppetto> +1
17:48:49 <limburgher> +1 also.
17:49:02 <SmootherFrOgZ> +1
17:49:05 <spot> +1 to 156
17:49:43 <rdieter> +1
17:49:44 <tibbs|h> Although, WRT 156, the review submitted didn't show any capability to build without the boot image.
17:50:10 <tibbs|h> I assume that it is something that can be generated once the compiler is actually in the distro.
17:50:19 <spot> tibbs|h: yeah, the exception is a temporary one, just to get the first build done, there must be an immediate secondary build to drop the bootstrapping
17:50:56 <spot> i see +6 on 156
17:50:57 <racor> Errm, 155 is the factor bootstrap issue... what are we voting on?
17:51:01 <tibbs|h> Usually it's actually shown how that will be done as part of the review, but I guess there's no requirement.
17:51:06 <spot> sorry, 155
17:51:11 <spot> off by one
17:51:12 <tibbs|h> And, derp, I meant 155 as well.
17:51:22 <rdieter> 156 was the source availability thing
17:51:25 <tibbs|h> Staring at it here on the screen; just can't type.
17:51:37 <spot> yeah, 156 is done, we're on 155, and once that's done, we'll go back to EnvironmentFile. :)
17:51:48 <tibbs|h> rollin'.
17:51:49 <abadger1999> +1 to 155 --  I'd like the post-bootstrap to be shown as part of the review.
17:51:53 <rdieter> 155 +1
17:51:57 <spot> +1 155
17:52:14 <racor> -1 ... bootstrap images should be a one- time thing to seed initial bootstrapping, but need to be rebuildable once bootstrapped
17:52:41 * rdieter doesn't see how voting -1 supports being able to bootstrap here
17:52:44 <abadger1999> May have to add that to the guidelines... for this particular case, I think we could just note it in the ticket.
17:52:47 <SmootherFrOgZ> +1 155
17:53:02 <spot> racor: i think you are saying the same thing as the rest of us. that an initial exception to get the first package built is okay, but it must be immediately rebuilt without it afterwards.
17:53:18 * rdieter assumes that's that "bootstrapping" means
17:53:32 <rdieter> though I suppose being explicit doesn't hurt
17:55:04 <spot> Okay, lemme propose explicit language:
17:55:10 <spot> "A temporary exception has been granted for bootstrapping Factor. Please note, this exception is limited to only the initial build of the Factor package. You may bootstrap this build with the binary "boot image", but after this is complete, you must immediately increment Release, drop the bootstrap "boot image", and build completely from source."
17:56:29 <racor> spot: this last sentence would get a +1 from me.
17:56:47 * spot is +1 to that language as well
17:56:59 <rdieter> +1
17:57:21 <tibbs|h> +1 Seems OK with me; can we get that into the actual bootstrapping guideline?
17:57:25 <limburgher> +1
17:57:31 <geppetto> +1
17:57:37 <limburgher> And +1 to tibb's suggestion.
17:57:45 <spot> tibbs|h: yeah, i can do that too
17:57:45 <limburgher> It should be common sense, but. . .well. . .
17:58:01 <SmootherFrOgZ> +1
17:58:26 <spot> #action bootstrapping exception granted, also add explanatory text (+1:6, 0:0, -1:0)
17:58:34 <tibbs|h> To be honest I think doing the whole bootstrap build/bump/non-bootstrap build should be part of the review.
17:58:39 <spot> okay, lets consider abadger1999's proposed wording
17:58:55 <spot> tibbs|h: tough to do if its your first package
17:59:40 <tibbs|h> Not really; if you can build it, you can certainly build it twice.
18:00:12 * spot is happy to leave this up to the reviewer, its rather uncommon as is
18:00:17 <tibbs|h> Indeed.
18:01:57 <spot> I'm +1 on abadger1999's draft on environment files
18:02:12 <geppetto> where is it?
18:02:20 <abadger1999> https://fedoraproject.org/wiki/User:Toshio/SystemdEnvFiles
18:03:21 <geppetto> I would do s/should always include/should include/
18:03:30 <geppetto> but +1
18:03:35 <rdieter> +1
18:03:36 <tibbs|h> To be perfectly honest, I'm not sure the last paragraph is even entirely correct now.
18:03:53 <spot> should always == must ?
18:03:56 <tibbs|h> But that was from the original, and is kind of outside the scope.
18:04:31 <geppetto> spot: that's how it could be read … but I think just plain should is better.
18:04:35 <SmootherFrOgZ> +1 on the draft
18:04:47 * spot is fine with it being a should
18:05:04 <limburgher> +1
18:05:19 * abadger1999 changes to should
18:05:21 <tibbs|h> The "should always" is from the original, isn't it?
18:05:24 <limburgher> should is good.
18:05:36 <racor> Is "you may refer to variables set in the /etc/sysconfig/..." true? In early stages of F16, I had encountered issues with yp* were this did not work.
18:05:37 <spot> I see +5 on the draft, with s/should always/should/
18:05:55 <abadger1999> tibbs|h: it was
18:06:02 <spot> racor: if EnvironmentFile is set, it should work
18:06:07 <tibbs|h> OK, just making sure.
18:06:20 <spot> if not, thats a bug.
18:06:41 <tibbs|h> To be clear, this is weakening the implied requirement of stuff to be in /etc/sysconfig.
18:06:46 * spot nods
18:07:06 * spot really does not want that particular holy war
18:07:13 <racor> spot: I don't know the details. The issue there was sysv /etc/sysconfig/* files were full fledged sh-scripts, while systemd's /etc/sysconfig/* files aren't.
18:07:22 <tibbs|h> Which, to be honest, I'm not particularly happy about, but at least is isn't unclear now.
18:07:38 <abadger1999> tibbs|h: Minor changes ot the last paragraph:  is it better now? https://fedoraproject.org/wiki/User:Toshio/SystemdEnvFiles
18:07:56 <spot> racor: really? i never saw sysconfig files that were shell scripts, i wouldn't have expected that to work in either model.
18:08:09 <tibbs|h> abadger1999: Well, actually the right way to do that is to use .include and not copy the file at all.  At least as I understand things.
18:08:18 <spot> unless they were doing something very wacky in the sysv init script to set the variables
18:08:35 <limburgher> spot: Unpossible!
18:08:54 <tibbs|h> I've used them as shell scripts, yes.
18:09:12 * spot sighs
18:09:14 <abadger1999> tibbs|h: Hmm.... I'd be fine with changing the recommendation but I don't know what all is possible.  If you want to rewrite the upstream recommendation that's fine with me :-)
18:09:31 <spot> "hey, my sandwich is also an mp3 player! wanna have lunch or listen to some music?"
18:09:35 <rdieter> well, there's /etc/sysconfig/network-scripts , but we'll give them a legacy-pass
18:09:37 <tibbs|h> It is pretty common to need to get the proper kerberos principals set up for services by just stuffing shell code into a sysconfig script.
18:10:21 <racor> spot: sysv's sysconfig were sh-scripts. systemd's aren't. This broke sh-ish var-expansion some /etc/sysconfig/yp* files had relied upon.
18:10:25 <spot> tibbs|h: yes, well, you said kerberos, and my brain immediately flipped into "bad idea" and shut off.
18:10:32 <tibbs|h> abadger1999: Indeed, I've had someone tell me that said paragraph in the guidelines is outdated but nobody submitted a draft for fixing it.  And I'm not sure of all the rules with that stuff.
18:11:04 <tibbs|h> Heh, both kerberos and yp as examples in the same discussion.
18:11:11 <tibbs|h> Heads should be exploding right about now.
18:11:11 <abadger1999> Does systemd just treat them as key value pairs?  Or is some shell acceptable like $(echo 'hi there')
18:11:40 * spot doesn't know, but i think at 71 minutes into the meeting, its not terribly relevant to this approved draft. :)
18:11:49 * rdieter covers ears, la la la
18:11:53 <abadger1999> +1 approve the draft :-)
18:12:01 * rdieter has to go soon too
18:12:08 <spot> #action Toshio's draft is approved (+1:5, 0:0, -1:0)
18:12:08 <tibbs|h> +1 it's at least clearer.
18:12:51 <abadger1999> Well before we go
18:13:01 <abadger1999> rubygem guidelines
18:13:10 <spot> abadger1999: are they ready?
18:13:20 <racor> 0 for Toshio's draft
18:13:23 <abadger1999> I went with my recommendations because nobody seemd to have plausible cncerns
18:13:42 <limburgher> :)
18:13:45 <geppetto> abadger1999: they weren't ever meant to haved shell in them … but I'm 99% sure systemd enforces that now
18:13:47 <abadger1999> If someone here thinks there was a plausible concern and can restate for me, go ahead.
18:14:01 <abadger1999> I ran into one new wrinkle
18:14:17 <tibbs|h> Man the systemd documentation is hard to navigate.
18:14:37 <abadger1999> This one having to do with whether jruby, ruby, etc should all Provide: ruby(abi) or if we need more than that.
18:14:53 <limburgher> That is sticky.
18:15:02 <abadger1999> That's the only thing outstanding on voting on the draft the first time.
18:15:16 <abadger1999> Draft is here: https://fedoraproject.org/wiki/User:Toshio/RubyPackagingDraft
18:15:26 <abadger1999> I've posted it to the FPC ticket.
18:15:39 <spot> since it only got added today
18:15:42 <tibbs|h> For the record, EnvironmentFile does no fancy parsing; just commenting and whitespace stripping unless you use quotes.
18:15:43 <limburgher> I would think that it could, if you can use jruby on the gems as installed, i.e. they're interpreter-agnostic, but I don't know ruby so I can't say.
18:15:48 <geppetto> Are there any ruby people here?
18:15:53 <spot> i propose we give the ruby sig a week to chew on it and lead the agenda with it next week
18:16:00 <tibbs|h> spot +1
18:16:00 <limburgher> spot: <nods>
18:16:04 <abadger1999> If people are just watching the Ruby SIG's page, they won't see it....
18:16:20 <racor> I am sorry, real life interfers. I regret, my time's up, I've got to leave now.
18:16:23 <tibbs|h> I am really curious to know how on-board the ruby folks are with this.
18:16:26 <abadger1999> Would people here care to give it a once over and then I'll move it back to the Ruby SIG's RubyPackagingDraft page?
18:16:38 <abadger1999> tibbs|h: I think, not really at all.
18:16:57 <abadger1999> tibbs|h: But they refused to test my changes whereas I did and they do work fine.
18:17:03 <limburgher> racor: <waves>
18:17:10 <geppetto> I'd heard they were unhappy, but it mainly seemed to be due to how long it was taking to approve … and I told them to show up at the meeting
18:17:11 <tibbs|h> An impasse is a bad thing here.
18:17:12 <abadger1999> So I'm not sure what to do with that.
18:17:28 <tibbs|h> I mean, this has taken a long time.
18:17:43 <tibbs|h> But it looks to me as if they hoped we wouldn't look at it too closely.
18:17:51 <geppetto> Yeh, but my impression was that they thought it would take less time because we'd just rubber stamp what they proposed.
18:18:05 <abadger1999> yeah.  They didn't think there was a problem with the non-standard way they did things.
18:18:45 <abadger1999> When we told them it was a problem, they decided to insist on their method rather than helping to find and test a solution.
18:19:15 <spot> abadger1999: fwiw, your draft seems sensible to me, and also makes me never want to touch ruby.
18:19:15 <tibbs|h> This is a tough one.
18:19:18 <geppetto> spot: But, yeh, given nobody is here … I guess close it out and we'll deal with it first thing next week.
18:19:27 <rdieter> so, how insistent does fpc want to be on enforcing the separate %prep, %build, %install steps?  seems to be that's where most of the impasse is
18:19:32 <geppetto> spot: I had that desire before though :)
18:19:42 <limburgher> abadger1999, spot: I have to touch ruby at work, and if it all followed this draft, it like it better.
18:19:42 <abadger1999> to be fair, some of the ruby people have been open to discussion but they all seem to be missing some of the basic foundations of good distro packaging.
18:20:02 <tibbs|h> RIght, the sticking point is really down to the gem tool having to do everything itself.
18:20:02 <spot> rdieter: honestly, since it can be done with minimal effort, i don't see why we wouldn't enforce it
18:20:11 <limburgher> abadger1999: <nods>  I've seen that among many ruby coders, as well.
18:20:27 <rdieter> ok, just checking.
18:20:31 <abadger1999> rdieter: After looking at some ruby packages, I think that combined %prep, %build %install leads to more unreadable packages.
18:20:43 <rdieter> I don't disagree
18:20:45 <geppetto> Yeh, unless they come up with a good reason … and atm. their reasons are more "we don't want to"
18:20:58 <abadger1999> For instance, I think the prevalence of sed in ruby packages is partly because %patch can't be used at the most opportune time.
18:21:02 <spot> okay, we'll pick this up next week.
18:21:53 <spot> Thanks everyone.
18:21:58 <tibbs|h> abadger1999: That's an interesting point.
18:21:58 <spot> #endmeeting