16:08:57 <spot> #startmeeting Fedora Packaging Committee
16:08:57 <zodbot> Meeting started Wed Feb 23 16:08:57 2011 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:08:57 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:09:02 <spot> #meetingname fpc
16:09:02 <zodbot> The meeting name has been set to 'fpc'
16:09:05 <spot> #topic Roll Call
16:09:09 <geppetto> here
16:09:55 <abadger1999> here
16:10:47 <limburgher> here
16:10:58 <spot> fpc ping: SmootherFrOgZ, rdieter_work, tibbs|h
16:11:19 <tibbs|h> I chimed in earlier, sorry.
16:11:29 <spot> well, with me, that makes 5
16:12:15 <spot> hopefully other folks will join us later, but we'll give it a shot. :)
16:12:41 <spot> #topic Ticket 60 Results - https://fedorahosted.org/fpc/ticket/60
16:13:59 <spot> #action Voting on ticket 60 (+1:6, 0:0, -1:3)
16:14:30 <spot> Rather than spend any more time arguing about it, i'm just going to let FESCo know of the decision and move on
16:14:36 <abadger1999> <nod>
16:14:50 <nirik> If fesco is handling this, I would like to note that we are open to feedback on the proposed guideline, etc... please add to our ticket...
16:14:56 <spot> #topic Packaging Ada draft - https://fedorahosted.org/fpc/ticket/56 - https://fedoraproject.org/wiki/User:Landgraf/Packaging_Ada
16:15:06 <Rombobeorn> I'm here to answer questions about the draft, but I have a tiny keyboard so I may be a bit slow.
16:15:07 <tibbs|h> This has been significantly cleaned up recently.
16:15:39 <landgraf> I'm here as well
16:16:05 <tibbs|h> Why "SHOULD NOT" instead of "MUST NOT" for the last three options under "Devel packages"?
16:16:49 <spot> yeah, those seem like MUST NOT to me
16:17:08 <tibbs|h> Actually there's a lot of switching between should and must in the document, and I'm unsure of whether there are fine distinctions I'm missing.
16:17:15 * spot nods
16:17:28 <limburgher> Agreed
16:18:02 <spot> in fact, i would go so far as to say that the draft seems to make more sense with a global /SHOULD/MUST replacement
16:18:11 <tibbs|h> Is it expected that packagers will write their own project files?  Or is it normal for upstream projects to conform to these guidelines?
16:18:16 <tibbs|h> (Just tossing out questions.)
16:19:05 <Rombobeorn> Roughly speaking, I tried to follow the principle that if a MUST is volated, things won't work, if a SHOULD is violated, files will be harder to find to humans, or will be included unnecessarily.
16:19:08 <landgraf> tibbs|h: There are gpr in upstream packages. (In corect way)
16:19:40 <tibbs|h> OK, that's good to know.
16:20:14 <landgraf> tibbs|h: but packager should correct this file (include "with directories" for example)
16:20:19 <spot> Rombobeorn: we generally use MUST in situations where we want to enforce proper behavior and there is no obvious reason not to act in that fashion
16:20:23 <landgraf> this is Fedora-specific patch
16:20:36 <spot> or simply, we only use "SHOULD" when it is truly a "nice to have" item
16:20:40 <Rombobeorn> For PragmARC I wrote the gpr file. Not all projects have them.
16:22:12 <tibbs|h> Honestly besides the should/must thing I think this looks pretty good.
16:22:12 <landgraf> Yes, not all. but in most cases project  contains gpr
16:22:15 <Rombobeorn> spot: I'm OK with more MUSTs.
16:22:34 <tibbs|h> Does the executable stack thing cause issues with selinux?
16:22:58 <landgraf> Ok, I'll replace SHOULD to MUST in devel section.
16:23:16 <spot> i'd say if all the SHOULDs and MAYs were changed to MUSTs, i'd be fine with this draft. If it causes issues, and we need to loosen up a MUST or add a specific exception case, we can always do that
16:24:02 <tibbs|h> Agreed.
16:24:13 <limburgher> MUSTS make things simpler for packagers.
16:24:20 <limburgher> spot: nods
16:25:06 <spot> Rombobeorn, landgraf: are you okay with that?
16:25:50 <landgraf> what about "Project files SHOULD NOT contain hard-coded directory names, neither absolute nor relative". Some upstream projects contain hard-coded paths.
16:26:32 <landgraf> Do we have to replace correct hard-coded dir names?
16:26:35 <abadger1999> Rombobeorn, landgraf: What package provides the macros?
16:26:41 <abadger1999> Like GNAT_optflags
16:26:49 <spot> landgraf: okay, i would say we either want to reword it to make it clear that the packager is expected to replace the names, or that upstream provided files are exempt
16:27:03 <tibbs|h> landgraf: Well, if you're just going to accept whatever upstream provides there, what's the point of having a rule in the guidelines at all?
16:27:07 <spot> imho, i would say that the packager is expected to clean up the hard-coded dir names
16:27:18 <abadger1999> I think that's a MUST.
16:27:19 <Rombobeorn> spot: I don't want to change MAY to MUST in point 3 under GNAT project files.
16:27:20 <spot> we do this already for other scenarios.
16:27:33 <abadger1999> so packagers are expected to patch the source.
16:27:35 <geppetto> That's probably fine to stay as SHOULD … as long as you make it clear that it MUST use the correct Fedora paths (Eg. lib64 etc.
16:27:38 <spot> Rombobeorn: sure, thats fine
16:28:21 <abadger1999> The MAY in point 3 can just be de-emphasised.  It's an example, not a rule.
16:28:33 <landgraf> abadger1999: packages. which have configure have this flags. for other packages like xmlada I bring it in patch
16:28:41 <abadger1999> geppetto: That would conflict with current guidelines
16:29:19 <abadger1999> geppetto: https://fedoraproject.org/wiki/Packaging/Guidelines#macros
16:29:39 <Rombobeorn> abadger1999: RPM macros are in fedora-gnat-project-common.
16:30:08 <abadger1999> geppetto: mschwendt wrote that for directory macros to be effective in their purpose, they need to be matched in the build scripts.
16:30:12 <landgraf> abadger1999: not on spec file but in gpr.
16:30:20 <abadger1999> geppetto: Hard coding would contradict that.
16:30:30 <tibbs|h> So all Ada packages must have BuildRequires: fedora-gnat-project-common?
16:30:43 <landgraf> abadger1999: packager should use directories variable instaed hard-coded path
16:30:51 <landgraf> tibbs|h: yep
16:30:52 <tibbs|h> Or is that implicitly pulled in by something else?
16:31:01 <abadger1999> tibbs|h: <nod>  The f14 gcc-gnat does not dep on fedora-gnat-project-common so I think so.
16:31:04 <tibbs|h> If it's a hard requirement it needs to be stated in the guidelines.
16:31:09 <geppetto> abadger1999: If they are ever changed, then the builds will complain about unpackage/unfound files … and I'm pretty sure we have a bunch of non-ada packages that don't pass the macros all the way down
16:31:18 <spot> tibbs|h: yeah, that seems like a logical addition to this draft.
16:31:27 <abadger1999> geppetto: Currently we treat those as bugs.
16:31:37 <geppetto> abadger1999: Fair enough
16:31:40 <tibbs|h> I assumed the macros came with the compiler itself.
16:31:53 <abadger1999> geppetto: We can change the guidelines... but it should be a global change of guidelines.
16:32:35 <geppetto> abadger1999: Yeh, I don't care that much about making it easier :)
16:33:30 <spot> so... with all the SHOULD's changed to MUST's (except for that one MAY in item 3 of Devel Packages), + the additional MUST on the BuildRequires: fedora-gnat-project-common ...
16:33:43 <spot> are there any other concerns?
16:33:48 <landgraf> I think it's easy way to add fedora-gnat-project-common to gnat-gcc Requires...
16:33:55 <Rombobeorn> tibbs: Read under Compilation. Packages must build-require fedora-gnat-project-common.
16:33:58 <spot> landgraf: that would also work.
16:34:35 <spot> landgraf: but if you do that, you don't need that line in Compilation that Rombobeorn pointed out just now. :)
16:34:41 <tibbs|h> Rombobeorn: Recommended wording is "must have BuildRequires: fedora-gnat-project-common".
16:35:14 <Rombobeorn> tibbs|h: OK
16:35:15 <landgraf> spot: yes, but currently gnat-gcc doesn't have this Requires
16:35:22 <tibbs|h> "build-require" isn't a word.
16:35:44 <spot> landgraf: okay, then just keep that in mind, and let us know if it changes so we can make a quick edit.
16:36:21 * spot calls for a vote on the draft with the MUST changes and the wording change around the BuildRequires
16:36:30 <tibbs|h> +1
16:36:32 <spot> +1
16:37:14 <landgraf> BuildRequires has been changed
16:38:32 <limburgher> +1
16:38:50 <abadger1999> I think +1 -- there's two SHOULD's left that I'm not sure about.
16:38:58 <abadger1999> In the last section
16:39:18 * spot thinks those should be MUST
16:40:04 <landgraf> in file placement section?
16:40:06 * abadger1999 changes
16:40:08 <spot> landgraf: yeah
16:40:08 <tibbs|h> I thought they all got changed to must, sorry.
16:40:18 <tibbs|h> There we go.
16:40:29 <spot> geppetto: i think you're our missing voter
16:40:43 <geppetto> +1
16:40:55 <landgraf> yes, souce and specs  MUST be in {_includeir} ok
16:41:06 <spot> #action Ada draft, with MUST and BuildRequires changes, approved (+1:5, 0:0, -1:0)
16:41:23 <spot> landgraf, Rombobeorn: thank you for your work here, this was a pleasant draft to deal with. :)
16:41:36 <landgraf> thank
16:41:49 <Rombobeorn> Thanks.
16:41:53 <spot> #topic SystemD - https://fedorahosted.org/fpc/ticket/31
16:42:07 <spot> The outstanding issues discovered in testing these guidelines have not yet been resolved
16:42:13 <abadger1999> <nod>
16:42:13 <spot> So this draft will be tabled to next week
16:42:21 <abadger1999> also, there's additional scriptlets that we need
16:42:26 <tibbs|h> Ugh.
16:42:48 <spot> Moving on.
16:42:53 <abadger1999> If fesco allows a lot of autostart-services, then we sould prioritize the scriptlets that autostart services use.
16:43:04 <spot> #topic Octave - https://fedorahosted.org/fpc/ticket/61 - https://fedoraproject.org/wiki/PackagingDrafts/Octave
16:43:30 <abadger1999> We should make some note about bus activated services but we probably don't need the actual scriptlets for those in the initial guideline.
16:44:42 <tibbs|h> I'm not sure it's useful to dump the macro definitions into the guidelines like that.
16:44:45 <spot> looking over the Octave draft, I think the BuildRequires: in the noarch spec should be on octave-devel, not octave
16:44:47 <geppetto> Why does this draft have the list of macros and what they are … instead of a list of macros and what they do?
16:45:40 <spot> geppetto: yeah, that would be more useful here.
16:45:43 <tibbs|h> I'd move the spec templates down below stuff like naming, and remove obsolete stuff like %clean from the templates.
16:45:59 <geppetto> spot: Yeh, the "summary of differences" implies that too
16:47:23 <tibbs|h> One issue with guidelines that are composed almost exclusively of templates is they don't tell reviewers what to do with packages that differ from those templates.
16:47:26 <rdieter> hi, sorry I was awol, recovering from a migraine this morning.
16:47:31 <spot> i'm cleaning the templates now.
16:47:49 <abadger1999> We should also decide whether we want to move towards using macros in this way (%octave_pkg_install, etc) for everything or move away from it as well.
16:48:41 <spot> abadger1999: given the complexity of the install process (from the looks of the expanded macro), i'd say this is a positive item for this area
16:48:44 <abadger1999> It hides what's actually being done from the packager and sysadmins reviewing spec files which can make debugging or modifying harder.
16:48:44 <tibbs|h> In general I don't mind macros when they make things simpler.
16:49:04 <abadger1999> On other side of the equation, it mkaaes spec files higher level and easier to read if things are working right.
16:49:38 <geppetto> abadger1999: personally I'd prefer to move towards it
16:50:00 <geppetto> abadger1999: That way it's much easier to see when packages are "normal"
16:50:05 <spot> abadger1999: i think it is a case by case call, i don't want to macroize to a "suse" level, but this specific packaging area makes sense to me
16:50:25 <spot> just looking at what the macros would expand out to seems like a lot of needless pain if it is universally valid
16:50:55 <abadger1999> eh..
16:51:03 <spot> although "redhat package manager" isn't valid in the macro, should just be "RPM"
16:51:25 <rdieter> dunno if it had been mentioned, but stylistically, I'd prefer all these macros to have a %_ prefix
16:51:34 <rdieter> otherwise, quite slick.
16:51:41 <abadger1999> If we're willing to macroize other places as a general rule, then I'm good with this style.  If we're more inconsistent, I'm less so.
16:51:53 <spot> rdieter: there is a historical difference between %{_ and %{ macros
16:52:06 <spot> i think the %{_ are considered to be full path macros
16:52:07 <abadger1999> For instance, all python packages pretty much have a standard four or more lines of boilerplate at the top of the spec.
16:52:09 <tibbs|h> Well, where else could we save ten lines of crap with a single macro?
16:52:18 <abadger1999> We macroize that to be much simpler.
16:52:23 <rdieter> spot: ok.  good to know
16:52:38 <spot> abadger1999: i think we're willing to macroize other places in general, unless it is absurd
16:53:06 <tibbs|h> Honestly, if every single one of some type of package is going to need a pile of boilerplate, then hell yes, let's hide that behind a macro.
16:53:08 <abadger1999> Sounds good to me.
16:53:18 * abadger1999 just wants a consistent approach here.
16:53:23 <spot> abadger1999: *nod*
16:53:34 <tibbs|h> I'd surely love to see the current terrible python mess get simplified somehow.
16:53:36 <spot> i don't think we'd ever force macroization if a SIG was opposed to it
16:53:57 <abadger1999> local control works for me too.
16:54:03 <spot> but aside from that, when the macros make sense, why not?
16:54:24 <tibbs|h> I'd argue that we could use some more convenience macros for doing line ending or charset conversion.
16:54:32 <tibbs|h> But that we could lose some useless macros like __rm.
16:54:44 <spot> tibbs|h: but what if we move to Plan9? </troll>
16:55:15 <tibbs|h> <antitroll>Then we have bigger problems than fixing a few specfiles.
16:55:30 <tibbs|h> So, this draft....
16:55:37 <spot> So, i think the only cleanup here is that we need these macros broken out and described, as opposed to a barf of the macros file
16:55:47 <abadger1999> yep
16:55:57 <spot> also, if they're going to use _ macros, they should do so consistently
16:56:09 <tibbs|h> It looks like some of those macros are supposed to be internal.
16:56:12 <spot> (e.g. octpkgdir and octpkglibdir should be _ too)
16:56:21 <abadger1999> and move the examples below the other sections.
16:56:28 <spot> he may be using _ to indicate internal macros
16:56:31 <tibbs|h> Yes.
16:56:48 <spot> I'm fine with that, tbh, as long as it is made clear in the draft.
16:56:52 <tibbs|h> What did the R guidelines use for the complexity-hiding macros?
16:57:00 <spot> tibbs|h: whiskey.
16:57:17 <spot> sorry, that's what I used. ;)
16:57:34 <tibbs|h> I can't remember if they used underscores or not.
16:57:36 <geppetto> Also … what does everyone think of the macros having %{buildroot} in them?
16:57:37 <spot> actually, we obsoleted all of our macros a while back
16:57:50 <tibbs|h> I guess fonts are the only other place where we currently have that kind of macro in use.
16:58:00 <tibbs|h> Yeah, that's why I use the the past tense.
16:58:15 <tibbs|h> I was just looking for other examples.
16:58:28 <spot> tibbs|h: to be fair, the reason R did that was because upstream noticed how god-awful the things we were macroizing actually were and fixed them
16:58:43 <tibbs|h> Hooray, maybe there's a chance for that elsewhere.
16:58:44 <spot> not because we had an urge to move off macros. :)
16:59:11 <spot> geppetto: i think only that one macro has buildroot in it
16:59:32 <spot> and the octave_pkg_install macro kindof needs it. ;)
17:00:00 <spot> _octarchprefix has it because it is used in octave_pkg_install (and only there, i think)
17:00:02 <geppetto> I meant _octshareprefix and _octarchprefix
17:00:28 <abadger1999> It shoukd be separated
17:00:34 <spot> same answer, they're only used in octave_pkg_install
17:00:54 <spot> but it really only makes the octave_pkg_install macro a bit more complex
17:00:54 <abadger1999> consistency has %{buildroot} separated from the final dirnames always
17:01:07 * geppetto nods … I don't hate it … just what abadger1999 said
17:01:19 <abadger1999> I've got a hard stop guys.
17:01:35 <spot> okay, i'll follow up with orion on this one and we'll tackle it next week
17:02:18 <spot> #topic Open Floor
17:03:05 <tibbs|h> There are sporadic questions about whether we really require macros like _bindir instead of just using /usr/bin.
17:04:03 * nirik notes again feedback welcome at https://fedorahosted.org/fesco/ticket/544 if folks have concerns or suggestions for the proposed policy or list.
17:04:47 <tibbs|h> I understand we have to use _libdir but some of the macros just make things pointlessly longer.
17:04:52 <tibbs|h> _sharedstatedir or whatever.
17:05:13 <spot> some of them are just historical, tbh
17:05:14 <tibbs|h> I've never been sure what the point of macroizing all of that was.
17:05:32 <spot> i'm not sure there is any value in attempting such a large scale overhaul
17:05:48 <spot> and the pro could be argued that it minimizes typos. ;)
17:05:52 <tibbs|h> Well, certainly removing them from old packages isn't something we'd want to do en masse.
17:06:21 <tibbs|h> I'm not sure that using something that's longer minimizes typos.
17:06:33 <spot> hehe
17:06:38 <tibbs|h> I think this is one of those "rpmlint guidelines".
17:06:42 <spot> i said it could be argued, not necessarily that i was.
17:06:57 <tibbs|h> Where the guidelines don't really say, but rpmlint complains so people assume it's in the guidelines.
17:06:57 * abadger1999 no longer has a hard stop
17:07:01 <spot> i do think it also falls into the "it ain't broke, don't fix it"
17:07:08 <tibbs|h> abadger1999: Your stop softened?
17:07:45 <abadger1999> The only justification I've seen is "if the paths changed (in FHS, etc) later then the change could be made without package changes"
17:07:56 <spot> tibbs|h: no, the guidelines do actually say
17:07:59 <geppetto> tibbs|h: Well if you typo /usr/share/daat … rpm will just use a different dir. if you typo %{_sharedstatedri} it doesn't work
17:08:06 <spot> https://fedoraproject.org/wiki/Packaging/Guidelines#macros && https://fedoraproject.org/wiki/Packaging:RPMMacros
17:08:25 <tibbs|h> spot: Yeah, but that's kind of an odd guideline.
17:08:42 <spot> granted, but again, "if it ain't broke"...
17:09:05 <tibbs|h> I'll argue that anything that require you to replace /etc with %{_sysconfdir} is indeed broken.
17:09:15 <spot> i believe the historical reason involves supporting alternate prefix
17:09:22 <tibbs|h> /var is even worse.
17:09:28 <spot> and the difference between prefix and exec_prefix
17:10:01 <tibbs|h> Except that one is defined to the other....
17:10:20 <spot> fwiw, i have had the situation where i was replacing /etc with _sysconfdir and realized that the file in /etc really shouldn't be there as a result
17:10:27 <spot> but that isn't necessarily a rationale
17:10:42 <spot> tibbs|h: they used to be different in the long-long time ago
17:11:06 <abadger1999> I'd be okay with allowing non-macroized pathnames if there's no other reason to keep the rule than what we've said so far.
17:11:16 <tibbs|h> Anyway, it's just idle chat.
17:11:35 <spot> abadger1999: again, i'm in the camp of "not broke, doesn't need a fix", because making this change will also make rpmlint noisier
17:11:41 <spot> and i could hack up rpmlint, but i'd rather not
17:11:47 <tibbs|h> I do wish we could somehow suggest against %{__cp} and the like.
17:12:01 <spot> tibbs|h: now that i would support
17:12:16 <spot> and i do not believe we mandate their use anywhere currently, just the directory location macros
17:12:22 <tibbs|h> Indeed.
17:12:29 <spot> draft it, please. :)
17:12:34 <tibbs|h> But I recognize that the only thing they hurt is my wrists.
17:12:45 <tibbs|h> Sure, I'll draft it.
17:12:47 <spot> and my eyes, oh god, the goggles, they do nothing
17:13:04 <tibbs|h> Yeah.  It's just painful to look at.
17:13:12 <geppetto> :)
17:13:22 <tibbs|h> In a review, someone argued that they were required because the guidelines used %__sed in one place.
17:13:25 <spot> "Macros which are longer than the name of the command they execute are stupid."
17:13:28 <limburgher> They should make glasses that support sed for just this reason. . .
17:13:50 <tibbs|h> I found the reference and changed it to just use plain "sed".
17:13:53 <abadger1999> extra guidelines are broken... I mean -- just now with the ada guidelines we said that you have to fix hardcoded paths in upstream build scripts
17:13:56 <spot> tibbs|h: good for you.
17:14:17 <abadger1999> as an effect of the macroizing path guidelines.
17:14:22 <tibbs|h> abadger1999: I don't follow you.
17:14:36 <tibbs|h> What do you mean by "extra guidelines"?
17:14:45 <abadger1999> macroizing paths -- spot
17:15:27 <spot> abadger1999: a valid point, i suppose.
17:15:31 <abadger1999> 's saying that if the macroizing path guidelines aren't causing problems, don't change them
17:15:53 <abadger1999> They aren't causing "problems" but they do affect the other guidelines that we make and the work that maintainers do.
17:15:54 * spot wouldn't honestly lose sleep if we dropped that item from ada
17:16:17 <spot> i don't think that makes it inconsistent with the larger "use macros in specs for directory locations" guideline
17:16:19 <abadger1999> <nod>  as long as it's consistent, I'm fine with it too.
17:16:53 <tibbs|h> Maybe I was misunderstanding the reason for that in the ada guidelines.
17:17:50 <abadger1999> In general with new guidelines we try to say that things that are unnecessary to specify are maintainer perogative... If there's no benefit to using the macroized versions of dirnames, it seems like something that should fall back to maintainer perogative.
17:17:52 <spot> to be fair, i think they were referring to using Ada variables, not rpm macros in that item
17:18:05 <tibbs|h> I agree.
17:18:07 <spot> e.g. "Directories.Libdir"
17:18:30 <spot> abadger1999: yeah, i would support that as well.
17:18:41 <spot> draft it, we'll look at it. :)
17:18:46 <abadger1999> Sounds good.
17:19:06 <spot> Okay, I have about 50 billion things to do today, so i'm calling this meeting.
17:19:08 <spot> thanks everyone.
17:19:10 <spot> #endmeeting