16:01:42 <spot> #startmeeting Fedora Packaging Committee
16:02:01 <spot> #topic Roll call
16:02:05 * limburgher here
16:02:42 <spot> abadger1999, tibbs|h, racor, rdieter, SmootherFrOgZ: ping
16:02:57 <abadger1999> spot: here
16:02:58 <rdieter> here
16:03:14 <rdieter> might not be able to stay the whole hour tho
16:03:25 <racor> here
16:04:20 <spot> okay, well, for once, we don't have a ton of stuff on the agenda
16:05:12 <spot> i count 5 in attendance, so that is quorum (barely)
16:05:25 <limburgher> <golfclap>
16:05:56 <spot> #topic Fortran: https://fedoraproject.org/wiki/PackagingDrafts/Fortran
16:07:03 <limburgher> First language?  Umm, assembly?
16:07:25 * spot notes that the items under "Required changes" aren't part of the guidelines
16:07:40 <mcepl> spot: Guideline rule no. 1 "Just don't do it!" ;-) (sorry, cannot resist)
16:08:02 <limburgher> #2 Don't talk about the Guidelines. . .
16:08:15 * SmootherFrOgZ is here now
16:09:35 <spot> does anyone think there are issues with this draft?
16:09:57 <spot> (aside from a possibly specious claim to being the first programming language)
16:10:16 <spot> i think it is safer to say "first high-level programming language"
16:10:31 <limburgher> spot: Agreed.
16:11:10 <spot> for the most part, this is simply codifying how fortran bits should be built and packaged, which seems reasonably sane.
16:11:24 <limburgher> I don't see any major gotchas.
16:12:03 <SmootherFrOgZ> sound good to me
16:12:25 <spot> Okay, lets take a vote then
16:12:28 <spot> +1
16:12:40 <SmootherFrOgZ> +1
16:12:42 <limburgher> +1
16:12:49 <racor> i recall jacub having pronounced reservations against early drafts - Have these been clarified
16:12:58 <rdieter> it replaces those other 2 Fortran-related drafts, but includes much less too, for better or worse.
16:13:12 <spot> racor: jakub's concerns were around whether %{_fmoddir} was versioned or not
16:13:27 <spot> racor: afaik, that is still up in the air
16:13:41 <racor> yep, this matches to what I recall.
16:13:52 <rdieter> +1, succinctness is a virtue I guess
16:13:55 <spot> but, since this draft doesn't define %{_fmoddir}, simply says to use it, there is flexibility to resolve that later
16:14:14 <racor> +1
16:14:39 <spot> #action Fortran draft passes, goes to FESCo for ratification
16:15:03 <spot> #topic Script Interpreters https://fedoraproject.org/wiki/Script_Interpreters_%28draft%29
16:15:21 <abadger1999> +1 for fortran
16:15:28 <abadger1999> spot: One more thing about fortran
16:15:35 <spot> abadger1999: yes?
16:15:42 <abadger1999> the end of the draft lists two possibilities for fmoddir
16:15:47 <abadger1999> Do we want to decide that now?
16:16:00 <spot> abadger1999: i'm going to try to get jakub's feedback first
16:16:08 <abadger1999> the referenced bug seems to be stalled on someone making a decision: https://bugzilla.redhat.com/show_bug.cgi?id=483765
16:16:09 <buggbot> Bug 483765: low, low, ---, jakub, ASSIGNED, please have libgfortran own %_libdir/gfortan %_libdir/gfortan/modules
16:16:28 <abadger1999> according to that bug jakub thinks the versioned ddirectory is the right answer.
16:16:49 <spot> yeah, but i still want to talk to him
16:17:01 <spot> just to make sure he has considered the information in comment 2
16:17:07 <abadger1999> spot: Sound sgood.
16:17:25 <abadger1999> onward and upward
16:18:04 <spot> so, the biggest downside to not using env is that it would make it more difficult to mix Fedora packages with a local copy of the script interpreter, is that right?
16:18:08 <limburgher> I just fixed a typo in the env draft
16:18:45 <limburgher> spot:  Pretty much. But, given Fedora's bleeding-edgeness, how often does this come up?
16:19:00 * spot shrugs
16:19:08 <tibbs|h> Ugh.
16:19:09 <racor> on each devs desktop, when testing interpreters
16:19:23 <tibbs> Sorry, folks, I had trouble getting away.
16:19:25 <spot> i just know that in perl, the p5p folks often advocate for users to simply build a local copy of perl
16:19:31 <spot> tibbs: no worries
16:20:06 <rdieter> fixing everything will be mildly painful, and often not upstreamable... question is:  is it really worth it?
16:20:18 <abadger1999> spot: Note that mixing of script interpreters is also the biggest drawback.
16:20:26 <spot> abadger1999: agreed
16:20:43 <abadger1999> So it's both a feature and an issue of env.
16:21:02 <spot> abadger1999: perhaps if we had some documentation on how a user who wishes to use a local interpreter can do so?
16:21:16 <tibbs> Honestly  I'm ambivalent on the env thing.
16:21:25 <spot> it seems like a legitimate, if uncommon, use
16:21:34 <limburgher> agreed.
16:21:46 <abadger1999> rdieter: The pro would be that I can install a local version of perl/python/etc for my particular scripts and it won't interfere with the system even if it is in the path.
16:22:14 <rdieter> I know, I'm with tibbs, torn.
16:22:39 <abadger1999> spot: So how would a local interpreter be used?
16:22:46 <limburgher> Me too, but leaning in favor, for rpm dep reasons.
16:23:03 <abadger1999> If it was used for all programs, it would definitely break some programs.
16:23:06 <rdieter> may end up being easier to fix rpm to be smarter here.
16:23:11 <spot> limburgher: yes, but given that this is a very specific single case, it should be possible to teach the rpm dep scripts how to deal with /usr/bin/env
16:23:36 <limburgher> spot:  Good point.
16:23:46 <abadger1999> but a more targetted use... I don't know environment-modules might allow someone to do that but not much else.
16:24:20 <rdieter> is this being positioned as a MUST or SHOULD type thing?  I'd be ok with it not being mandatory at least.
16:24:23 <abadger1999> <nod> I also think the dep issue has workarounds.  For instance, specifying the dependency manually.
16:24:31 <abadger1999> MUST.
16:24:37 <limburgher> abadger1999: true
16:24:44 <abadger1999> I hate should's... they're a bit of why even write it?
16:24:47 <spot> I think that given that most upstreams will not take these patches, and the rpm problem is solvable, the only reason to take this action is to ensure a consistent environment even if the user inserts their own interpreter
16:25:00 <spot> is that a correct assessment?
16:25:11 <tibbs> Seems correct to me.
16:25:16 <abadger1999> Assuming we can get hte changes into rpm, that's my assessment too.
16:25:40 <spot> So, we need to weigh that benefit against the burden of carrying patches that upstreams may never take.
16:26:29 <limburgher> spot: We do a lot of that anyway. :)
16:26:30 <spot> I think that we already carry patches that upstreams will not take for one reason or another.
16:27:02 <rdieter> I just don't see it being worth it, honestly.  having custom/local interpreters falls in the "you break it, you keep the pieces" category for me
16:27:14 <spot> Also, I think that a user who is intelligent will be able to either not mix system packages and locally built bits sanely
16:27:30 <spot> (or rather, to do so sanely)
16:27:38 <racor> my opinion: Fix rpm and don't mandate SHOULD nor MUST
16:28:21 <spot> The only reason I would think this is a good idea would be to protect uninformed users from poor advice on the internet (build perl from source and your bug automagically goes away!)
16:28:56 <spot> But in the same breath, I'm not sure that is a huge problem now.
16:29:21 <limburgher> Yeah, I'm coming around to how rdieter just put it.
16:29:54 <spot> I think we can revisit something like this if we see a lot more bugs on such cases.
16:30:09 <spot> But as is, I'm inclined to simply fix the rpm dep scripts to parse /usr/bin/env
16:30:34 <spot> So, lets vote on this draft
16:30:36 <spot> -1
16:30:39 <abadger1999> there are bugs about this open.
16:30:49 <spot> abadger1999: oh?
16:31:09 <limburgher> -1
16:31:19 <tibbs> It's pretty easy to imagine such bugs.
16:31:47 <spot> Okay, does any other distribution have a similar policy?
16:31:55 <tibbs> I mean, you can break all of the admin tools in the system by sticking anything called python ahead of your path.
16:32:12 <abadger1999> spot: Yeah.  Unfortunately, they're against RHEL so they're not viewable.
16:32:26 <tibbs> If I were packaging python stuff, I'd certainly get rid of env.
16:32:37 <tibbs> I'm just not sure it makes sense to force everyone to do it.
16:32:53 <abadger1999> They're about places that depend on having specific versions of python for their local scripts and those versions of python break the system tools.
16:33:19 <abadger1999> They go into the fact that LSB specifies /usr/bin/python must exist on a system, therefore the vendor supplied scripts should use /usr/bin/python.
16:33:20 <tibbs> In a way it's sort  of like how we treat the #! thing on non-executables.
16:33:30 <rdieter> shrug, local scripts should point to their custom/specific interpreters then
16:33:34 <abadger1999> <nod>
16:33:35 <rdieter> vote: -1
16:33:35 <racor> -1 (But fix rpm's scripts)
16:33:44 <spot> I think I'm still -1 here
16:34:22 <spot> with the statement that any packager who wanted to do so is certainly not prohibited from doing so
16:34:32 <abadger1999> Debian has a recommendation: http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html
16:34:41 <abadger1999> section 3.1.2
16:34:49 <rdieter> It's a good best practice and all, but not MUST-worthy
16:34:52 <abadger1999> But gives the maintainer freedom to choose either way
16:35:00 <spot> "If a maintainer would like to provide the user with the possibility to override the Debian Python interpreter, he may want to use /usr/bin/env python or /usr/bin/env pythonX.Y. However this is not advisable as it bypasses Debian's dependency checking and makes the package vulnerable to incomplete local installations of python. "
16:35:24 <spot> I would be okay with adding similar language to our Python guidelines
16:35:39 <limburgher> <nods>
16:35:40 <tibbs> Not that you can trust debian for sanity here.
16:35:53 <spot> but that really makes it a SHOULD, not a MUST
16:36:06 <abadger1999> <nod>
16:36:40 <spot> abadger1999: if you'd like to draft up new language around that, as a SHOULD, i think it might get more support
16:36:43 <abadger1999> Debian does allow users to install multiple versions of python on their system.
16:37:09 <spot> #action Script Interpreters did not pass
16:37:15 <abadger1999> As a SHOULD, I just don't see the point of a Guideline... It more belongs in a tips and tricks document like we're always talking about.
16:37:46 <spot> abadger1999: fair enough.
16:37:58 <spot> #topic Common Voice Data: https://fedoraproject.org/wiki/PackagingDrafts/CommonVoiceData
16:39:02 <tibbs> I'm... not sure I get it.
16:39:05 <spot> i admit to knowing almost nothing about voice data
16:39:33 * rdieter doesn't remember seeing mention of this one before, did I miss it?
16:39:56 <spot> I think he just wants to standardize the naming, location of installed files, and some sort of database for tracking the phonemes
16:40:44 <tibbs> In general I don't think there would be objection to that.
16:40:55 <spot> Yeah, I think it is reasonably sane.
16:40:56 <tibbs> But as a guideline I think there's a lot to fill in.
16:41:14 <tibbs> Which part is the actual guideline?
16:41:33 <limburgher> tibbs: For example: handling by *what*?
16:41:46 <SmootherFrOgZ> tibbs: that should start at naming guideline stage for packages which provide such data
16:41:47 <spot> Yeah, there is a lot of handwaving in this
16:42:13 <tibbs> Is there even any standard for how individual applications will consume this data?
16:42:34 <spot> The "Post install" and "Dialect handling" are especially ... umm... vague.
16:43:03 <rdieter> gotta run, but having a basic naming guideline seems quasi-sane I guess.
16:43:06 <spot> I think we need to send this back to the author to flesh out with specific implementation details, as well as an example spec
16:43:29 <limburgher> spot: yup.
16:43:38 <spot> rdieter: thanks
16:44:00 <SmootherFrOgZ> spot: nod
16:44:05 <spot> if there are no dissents, i'll email dchen
16:44:34 <tibbs> I would still like to know what can actually consume this data in the proposed format.
16:44:46 <spot> tibbs: i'll ask that and about any existing standards
16:44:52 <tibbs> It does seem a bit pointless to have this database and data that nothing can use.
16:44:53 <racor> spot: ack
16:44:58 <limburgher> tibbs: Sounds like great fodder for a voicemail app.
16:45:38 <spot> #action Common Voice Data to be sent back to author to be fleshed out with specific implementation details, as well as an example spec
16:45:48 <spot> #topic Open Floor
16:45:51 <tibbs> It does, but that assumes that any app developers would actually use data in this format.
16:46:20 <limburgher> And not something homegrown.
16:47:26 <spot> okay, the floor is open to any other items
16:48:46 <abadger1999> Anyone on the FPC want to take over monitoring the mailing list for packaging drafts/packaging draft ideas that aren't getting all the way to the committee?
16:49:02 <tibbs> Just to go back to what I missed, is the Introduction section of the FORTRAN draft actually supposed to go in the guidelines?
16:49:25 * abadger1999 tries to sneak out of some work :-)
16:49:27 <tibbs> Because that's more cruft that shouldn't be in a guideline.
16:49:57 <tibbs> abadger1999: My available time right now is.... sparse.
16:50:08 <tibbs> I'm not even keeping up with fedora-devel.
16:50:12 <spot> my time is sparse and soon to be sparser.
16:50:16 <limburgher> abadger1999: what is entailed?
16:50:37 <abadger1999> tibbs: heh.  Yeah, I was more thinking of the new members that don't know what they're in for :-)
16:51:08 <abadger1999> limburgher: Basically, I try to monitor fedora-packaging and to a lesser extent fedora-devel for ideas that could easily become packaging guidelines.
16:51:31 <abadger1999> limburgher: Lots of times these pop up as, "this seems to violate the guidelines, can I do it anyway" posts.
16:51:40 <abadger1999> Where the rationale for violating the guidelines makes sense.
16:52:07 <limburgher> abadger1999:  Would I say, " write and submit to FPC", or do it myself?
16:52:08 <abadger1999> When that happens, I try to discuss how to turn it into a guideline, then write it up as a packaging draft and stick it on the agenda.
16:52:24 <spot> tibbs: I'm not opposed to trimming it out, although, it is possible someone doesn't know what Fortran is.
16:52:38 <abadger1999> Usually, I assume that the person doing the posting isn't going to do it themselves.
16:52:51 <limburgher> spot: Maybe a wikipedia link?
16:53:08 <limburgher> abadger1999: Ok.  I'll do it.
16:53:32 <abadger1999> limburgher: if I don't agree with the guidelines change, though, I do tell the person that they should either write it up or edit what I've written up or at the very least, show up at the FPC meeting to argue for it.
16:54:04 <abadger1999> limburgher: Excellent!
16:54:27 <abadger1999> Thank you :-)
16:54:28 <limburgher> abadger1999:  Sort of a, "that's a horrible idea, here's the best way to go about it"?
16:54:49 <spot> tibbs: i think we can safely drop the introduction
16:54:53 <abadger1999> Yeah, exactly.  And trying to bring up issues that you see in the idea to try to make it more palatable.
16:55:10 * spot goes ahead and drops it
16:55:12 <abadger1999> So when it does come to the committee it's not a total waste of time.
16:55:29 <limburgher> abadger1999:  Ok.  Maybe I'll keep a list of what I see, give the others a heads up if a doozy is brewing.
16:55:45 <abadger1999> cool.  that's perfect.
16:58:13 <abadger1999> limburgher: If you feel overwhelmed, you can have me step back in to help you do writeups.  I'm just feeling overwhelmed myself,  right now :-)
16:58:40 <spot> okay, if there are no other items, i'm going to close this meeting out
16:58:50 <limburgher> abadger1999:  Will do.
16:58:53 <limburgher> Nothing here.
16:59:12 <spot> thanks to everyone, we have finally worked through our backlog. :)
16:59:16 <spot> #endmeeting