16:05:03 <abadger1999> #startmeeting fpc
16:05:03 <zodbot> Meeting started Wed Nov  3 16:05:03 2010 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:05:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:05:13 <abadger1999> #meetingname fpc
16:05:13 <zodbot> The meeting name has been set to 'fpc'
16:05:29 <abadger1999> Alright, who's here?
16:05:34 <abadger1999> #chair tibbs
16:05:34 <zodbot> Current chairs: abadger1999 tibbs
16:05:39 <abadger1999> #chair geppetto
16:05:39 <zodbot> Current chairs: abadger1999 geppetto tibbs
16:06:17 <geppetto> spot is in the channel
16:07:08 <abadger1999> rdieter, SmootherFrOgZ, racor, ping fpc meeting
16:07:20 <rdieter> oh, pongy pongy
16:07:33 <abadger1999> geppetto: spot msg'd me that he got called into a meeting at work.
16:07:43 <abadger1999> #chair rdieter
16:07:43 <zodbot> Current chairs: abadger1999 geppetto rdieter tibbs
16:07:50 <abadger1999> Well, that's four.
16:08:02 <racor> i'm here, too
16:08:08 <abadger1999> #chair racor
16:08:08 <zodbot> Current chairs: abadger1999 geppetto racor rdieter tibbs
16:08:14 <abadger1999> Okay, that's quorum.
16:09:40 <abadger1999> I'll start with what spot sent in his email and then we'll see if we have time
16:09:58 <abadger1999> #topic Ban pretrans -- https://fedorahosted.org/fpc/ticket/22
16:10:27 <tibbs> I just opened it as a point of discussion.
16:10:33 <abadger1999> ah okay.
16:10:56 <abadger1999> Well -- it seems like there's nothing using it at the moment so there's not a big impact no matter what we do.
16:10:58 <tibbs> Occasionally people think %pretrans will solve some problem of theirs.
16:11:14 <abadger1999> But if people want to use it we should tell people that they must use -p lua
16:11:18 <tibbs> Generally they are dissuaded pretty quickly.
16:11:28 <rdieter> abadger1999: yeah
16:11:45 <geppetto> Yeh, one other piece of info. I saw recently was that hicham was trying to use it to do symlink => dir. moves in package upgrade … but that fails when you don't use rpm directly.
16:11:54 <tibbs> Anyway, is it worth just a sentence in the scriptlets section to expose what I guess should be obvious?
16:12:04 <tibbs> I'll propose something in the ticket.
16:12:04 <abadger1999> Yeah, sounds fine.
16:12:08 <abadger1999> Cool.
16:12:15 <geppetto> So I'm +1 for outright banning it, if anyone comes up with a usecase we can always unban it for them, no?
16:12:45 <geppetto> Yeh, at least telling them to use -p lua, is fine too :)
16:13:12 <abadger1999> I'm not maried to either one but lean towards just documenting to use -p lua.
16:13:43 <tibbs> The vast majority of people won't want to touch lua, so in practice they're probably the same.
16:13:49 <geppetto> :)
16:13:59 <tibbs> Anyway, I'll propose something.
16:14:09 <abadger1999> #action tibbs will write a sentence or two to add to ScriptletSnippets page
16:14:26 <racor> abadger1999: +1. If it's not useful, rpm should abandon it.
16:14:40 <abadger1999> #topic rpmlint clarifications --  https://fedorahosted.org/fpc/ticket/21
16:15:03 <tibbs> We were asked to do this ages ago but it seemed to have dropped through the tracks.
16:15:13 <abadger1999> Yeah, I'm +1 on this.
16:15:21 <abadger1999> At least, both srpm and binary.
16:15:41 <tibbs> Honestly, I probably should have just done this and not bothered the bureaucracy since it's pretty obvious.
16:15:42 <geppetto> Yeh, I don't see any problem with having it run on at least binary too
16:15:51 <rdieter> +1 "just do it"
16:15:55 <abadger1999> <nod>  it's really just clarification.
16:15:56 <abadger1999> +1
16:15:59 <tibbs> But it may be worth mentioning somewhere that installing the packages gets more output.
16:16:13 <tibbs> Although perhaps that's better left for rpmlint documentation.
16:16:35 <tibbs> I fear that rpmlint is in general diverging too far from our guidelines anyway.
16:16:44 <abadger1999> a sentence in the rpmlint section seems reasonable to me.
16:17:14 <tibbs> I'll make the change and propose an additional sentence about running rpmlint on installed packages.
16:17:22 <geppetto> Trying not to sidetrack this simple thing … but do we have any stats. on the rpmlint output (Ie. how many packages have 0 output, etc.)?
16:17:22 <abadger1999> Sounds good.
16:17:46 <abadger1999> geppetto: We don't yet.  The autoqa people might as rpmlint is one of the things they run.
16:17:54 <tibbs> geppetto: Well, technically no package should have zero output.
16:18:09 <tibbs> Because packages shouldn't have things like BuildRoot now, yet rpmlint will yell about it.
16:18:22 * geppetto nods
16:18:28 <abadger1999> #topic https://fedorahosted.org/fpc/ticket/20 -- Amend RequiringBasePackage to clarify -libs scenario
16:19:30 <geppetto> None commented since me … so let me say, I don't mind just doing what spot suggested … I was just trying to include lots of other things, like zsh-html etc.
16:21:00 <abadger1999> The specificity vs generalness of that section has bothered me in the past but I don't think the rewording gets at what spot was seeing.
16:22:27 <geppetto> Fair enough, as I said I'm +1 to spots wording … and we can always hope/assume non-libs sub-packages use common sense :)
16:22:56 <tibbs> Well, common sense (or lack of it, I guess) is the root of the problem here.
16:23:27 <tibbs> But spot's wording seems OK to me to at least cure the specific issue here.
16:23:50 * geppetto nods
16:24:41 <abadger1999> <nod>
16:25:55 <abadger1999> I think it would make sense for geppetto's changes to replace what's currently there about -devel packages and then add spot's -libs clarification after that.
16:26:43 <abadger1999> (geppetto's paragraph changes the emphasis from -devel packages to subpackages; spot's clarification is that -libs packages are a special kind of subpackage)
16:27:47 <abadger1999> Does that sound reasonable?  Do we want to vote on that?
16:28:18 <geppetto> Sure
16:28:22 <geppetto> I'm +1
16:28:23 <racor> I like geppetto's change, but don't like spot's. *-libs as an example would be OK with me.
16:29:22 <tibbs> That becomes contradictory to what we want, though.
16:29:45 <tibbs> The point is that the common case is that *-libs does not require the base package.
16:30:13 <tibbs> If you don't include spot's change, the language says that *-libs should require the base package.
16:30:40 <tibbs> And having a mere example that goes against the stated rule is confusing.
16:30:47 <geppetto> tibbs: Well, it's implicit in that -libs aren't extensions
16:31:00 <tibbs> The whole issue shows that it's better to be explicit.
16:31:05 <geppetto> tibbs: But, I agree, due to how this came up it'd be better to be explicit
16:31:13 <geppetto> beat me to it :)
16:31:56 <geppetto> I could come up with some other wording that explicitly says something like "do X for packages which are extensions" and "do Y for packages which aren't extensions"
16:32:07 <geppetto> And give a couple of examples
16:32:22 <tibbs> Better than an impasse, I'd agree.
16:33:01 <abadger1999> How about:
16:33:04 <abadger1999> "devel packages are an example of a package that must require their base packages using a fully versioned dependency.  -libs subpackages which only contain shared libraries do not normally need to explicitly depend on %{name} = %{version}-%{release} as they normally aren't needed by the base package at runtime."
16:33:22 <abadger1999> Replacing the last sentence in geppetto's revision.
16:34:04 <geppetto> that's fine by me
16:35:12 <geppetto> Maybe even adding something like "If the main package depends on the sub-package and the sub-package on the main package, you should think carefully about why you don't have everything in the main package"?
16:35:38 <abadger1999> I'd be fine with that too.
16:36:01 <tibbs> Is there some multilib reason why you'd do that kind of thing?
16:36:24 <geppetto> tibbs: It's possible … but my guess is most of the time it'd be the -libs kind of situation which caused this issue
16:38:16 <geppetto> So, +1 to my wording in the ticket, with the changes by abadger1999 and me?
16:38:22 <abadger1999> +1
16:38:42 <tibbs> +1
16:39:16 <racor> +1
16:40:02 <geppetto> rdieter: ?
16:40:25 <rdieter> sorry, +1
16:41:04 <abadger1999> #agreed the Requiring Base Package clarification by gepetto with abadger1999's wording passed.
16:41:13 <abadger1999> I'll write it up.
16:41:41 <abadger1999> The next two on spot's list were: https://fedorahosted.org/fpc/ticket/19
16:41:50 <abadger1999> and https://fedorahosted.org/fpc/ticket/15
16:42:07 <abadger1999> Those are both dealing with bundled libraries and I think that they're going to be a long discussion.
16:42:21 <abadger1999> So lets look at other tickets first.
16:43:08 <abadger1999> #topic new perl guidelines -- https://fedorahosted.org/fpc/ticket/23
16:43:43 <abadger1999> I think this is just that we haven't updated the draft yet.
16:43:53 <abadger1999> Err updated the guidelines to reflect the draft.
16:44:23 * geppetto nods
16:44:25 <abadger1999> Actually sorry...  confused by the report.
16:44:47 <geppetto> Well updated the TODO, based on the new guidelines by the SIG
16:45:35 * abadger1999 generates a diff
16:48:02 <abadger1999> copies of old and new guidelines: http://toshio.fedorapeople.org/perl.txt  http://toshio.fedorapeople.org/perl-draft.txt
16:49:16 <abadger1999> http://toshio.fedorapeople.org/perl-changes.diff
16:49:20 <tibbs> I don't really think the SIG stuff belongs in the guidelines.
16:49:55 * spot is here, apologies for the delay
16:50:36 <spot> some of the SIG stuff is at least useful for new packagers
16:51:15 <geppetto> Could we instead just point to a list of SIG guidelines? … or do we want to sign off on all their changes?
16:51:45 <abadger1999> things that are mandatory we sign off on.
16:51:47 <abadger1999> #chair spot
16:51:48 <zodbot> Current chairs: abadger1999 geppetto racor rdieter spot tibbs
16:52:23 <abadger1999> But the sigs can always have additional things that they, themselves, agree too (but that doesn't stop an outside reviewer from ignoring).
16:53:11 <geppetto> ok
16:53:31 <spot> the only change in this that is a little confusing to me is the removal of the "Core modules as buildrequires" section
16:54:07 <tibbs> Especially since the draft sill refers to that section.
16:54:21 * spot wonders whether that is an accidental removal or not
16:54:43 <tibbs> Oh, sorry, I'm confused about what is the draft and what is not.
16:55:04 <spot> -== Core modules as buildrequires ==
16:55:04 <spot> 
16:55:04 <spot> -Historically, buildrequiring a core module (that is, one provided by the perl package itself) has been frowned upon.  However, with the perl/perl-devel split, a number of core modules are now packages seperately from the perl package, and now need to be explicitly buildrequired:
16:55:04 <spot> -
16:55:05 <spot> -* perl(CPAN)
16:55:07 <spot> -* perl(Ext<code></code>Utils::Embed)
16:55:09 <spot> -* perl(Ext<code></code>Utils::Make<code></code>Maker)
16:55:10 <spot> -* perl(Test::Harness)
16:55:12 <spot> -* perl(Test::More)
16:55:13 <tibbs> Can we require that people format guidelines changes as a set of changes instead of just dumping us a single document and saying "we want it to look like this"?
16:55:14 <spot> -* perl(Test::Simple)
16:55:17 <spot> (from the diff)
16:55:32 <geppetto> but they have +
16:55:32 <geppetto> It is recommended to buildrequire core modules '''explicitly''', because they can move between sub-packages or disappear from core perl.
16:55:54 <spot> geppetto: okay, i see that.
16:56:34 <spot> so, in general, i'm okay with these changes then.
16:56:45 <spot> racor: what do you think, as you're pretty deep in perl?
16:57:07 <geppetto> I'm not sure it's as easy to notice as the giant section they removed, but it's still fine by me…
16:57:09 <abadger1999> update dep filtering with the changes that we added in ticket/16
16:57:29 <abadger1999> ie: cut it down to a few paragraphs that link to the filtering page.
16:57:32 <racor> spot: Sorry, was distracted on the phone, need to catch up ...
16:57:39 <spot> abadger1999: yeah, that makes sense.
16:57:51 <geppetto> The one thing that does tweak me a little bit is the new section on "Provides of binary vs. sub-package with separated binary" … do people really do sub-packages for that?
16:57:51 <abadger1999> This one I'm not sure about: == Provides of binary vs. sub-package with separated binary ==
16:58:01 <abadger1999> heh, jinx :-)
16:58:27 <abadger1999> yeah -- so subpackage disadvantage: hard to find in bugzilla.
16:58:35 <spot> geppetto: well, lemme put it this way: we don't explicitly forbid it.
16:59:02 <abadger1999> virtual provides disadvantage -- harder to find in a package list ( but yum search takes care of that for me)
16:59:14 <spot> i'm not usually a fan of unnecessary subpackages
16:59:30 <spot> but there are specific situations where i suppose they make sense.
16:59:47 <spot> in the case of perl, i suspect there aren't very many cases where it makes sense to put the binaries in a subpackage.
17:00:18 <geppetto> maybe, I don't think it has to die … but it seems a little weird to semi-recommend virtual sub-packages just so you get "FOO" into yum list output
17:00:32 <spot> geppetto: a good point.
17:00:49 <abadger1999> Also... not sure why we'd do this instead of following the same idea as php/python etc -- if the primary reason for the package is the application, use the application name rather than the module name.
17:00:55 <geppetto> spot: Do you know, what's the reason for not just renaming the main package?
17:01:03 <rdieter> imo, that section ought not be included at all (it's questionably correct, and isn't perl-specific either)
17:01:12 <spot> geppetto: because there is a naming requirement, i believe.
17:01:43 <spot> https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Addon_Packages_.28perl_modules.29
17:02:03 <spot> (which, i would note, invalidates that section)
17:02:35 <spot> I'd be more inclined to either drop the Provides of binary vs. sub-package with separated binary section entirely
17:02:56 <geppetto> But if read that way, then the python section just below requires yum be renamed python-yum
17:03:31 <geppetto> although I guess urlgrabber is named that way … so we are just completely random :)
17:03:35 <spot> geppetto: we've interpreted python a lot looser than perl. :)
17:03:48 <abadger1999> https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Addon_Packages_.28General.29
17:04:16 <racor> geppetto: besides what spot said, splitting perl-apps out from perl-modules shrinks the dependency tree of other packages only using the perl-modules.
17:04:20 <abadger1999> That section has a defintion of addon package that maybe should apply to all of the more specific naming guides.
17:04:41 <abadger1999> "If a new package is considered an "addon" package that enhances or adds a new functionality to an existing Fedora package without being useful on its own,"
17:05:07 <spot> racor: does it really? the -apps subpackage will still need the module base package. and other packages that just depend on the module base package will.... still depend on the module base package
17:05:30 <spot> racor: it does make the on-disk footprint a bit smaller, but most perl binaries aren't big enough to make a noticable difference
17:05:51 <abadger1999> spot: The -apps subpackage might also require something else though (like config file parsing or a gui toolkit)
17:05:56 <geppetto> racor: AIUI they can't putting the actual app. in the sub-pkg … just using it for the name
17:06:09 <spot> abadger1999: okay.
17:06:22 * spot would rather have this advice documented in a more generic way
17:06:29 <spot> as it is not really perl specific
17:06:41 <abadger1999> I think I agree with rdieter that this doesn't belong in the perl guidelines.
17:06:42 <racor> spot: yes. there are cases, where the "perl-modules" provided by a package providing "app" and a series of "perl-modules" are being used standalone.
17:06:43 <geppetto> That's two suggestions for that now, so +1
17:07:04 <tibbs> racor: Actually, spamassassin just came up as an example of this.
17:07:16 <racor> Also there are cases, where "app" is pulling in other perl-modules, which are not being required by its "perl-modules".
17:07:24 <spot> so, how about this draft, with that section removed, and put into a new ticket for a generic change.
17:08:05 <rdieter> spot: +1
17:08:24 <geppetto> spot: +1
17:08:28 <spot> +1 from me
17:08:41 <abadger1999> One last thing: this section was removed: = Makefile.PL vs Build.PL =
17:09:33 <racor> -1. there are sections I do not agree with. E.g. InitialCC perl-sig should remain, as well as perl SIG. Also the section referring to multiple directories "permitted to..." is wrong (should be must)
17:09:35 <abadger1999> I don't know what the reason for that is.
17:09:37 <spot> hm. i wonder why, as that advice is still accurate.
17:10:13 <racor> abadger1999: Agreed, it should remain
17:10:28 <spot> racor: the initial cc moved up to the top in the new version
17:10:31 <abadger1999> racor: The initialcc perl-sig seems to have been moved to the top of the page?
17:11:06 <tibbs> And it shouldn't reverence CVS anyway.
17:11:20 <tibbs> Fortunately there's a redirect.
17:11:39 <racor> spot,abadger1999: If you say so, I stay corrected ... however, wondering why I am not seeing it ;)
17:11:41 <spot> racor: the wording "permitted to" is more accurate here, as there are scenarios where some multiple dir ownership is unnecessary
17:11:53 <spot> +It's common practice to set the [https://lists.fedoraproject.org/mailman/listinfo/Perl-devel Fedora perl SIG mailing list]  as a member of the initial-cc list for bugzilla.  This can be done by adding the user <code>perl-sig</code> to the initial CC list when creating the [[CVSAdminProcedure#New_Packages|New Package CVS Request]].
17:12:02 * abadger1999 checks the original page to make sure
17:12:27 <tibbs> I see it just fine.
17:12:34 <abadger1999> racor: https://fedoraproject.org/wiki/PackagingDraft:Perl#Perl_SIG
17:12:37 <tibbs> the "Perl SIG" section near the top of the document.
17:14:18 <racor> spot: I vehemently disagree. Though  there are scenarios where multiple ownership is not strictly necessary (often temporarily), mandating multiple ownership helps keeping things KISS.
17:14:46 <spot> racor: eh, okay. it happens so regularly in perl, I suspect that may not be a bad idea.
17:14:47 <abadger1999> racor, spot: How about this change for the multiple directories:
17:15:06 <abadger1999> As specified in the [[Packaging:Guidelines#File_and_Directory_Ownership | general Packaging Guidelines]], perl packages are expected to share ownership of some directories.
17:15:21 <abadger1999> Hmm... maybe also s/some/certain/
17:15:26 <spot> abadger1999: okay, as well as changing "should" to "must" in the examples.
17:15:57 * spot is okay with those changes.
17:16:32 * spot points out that we are now at 75 minutes, I propose to table this for next week.
17:16:44 <spot> it will give me a chance to ask about that section removal
17:16:48 <spot> = Makefile.PL vs Build.PL =
17:17:15 <spot> anyone want to keep grinding on it instead? :)
17:17:31 <racor> abadger1999: Thanks for link, I now see it (I was diffing your perl.txt vs. perl-draft.txt and seem to have missed the perl-SIG section)
17:18:07 <tibbs> Nah, although the java folks did submit a draft.  It seems that the previous java guideline changes were not done by them and had nothing to do with them.
17:18:31 <spot> tibbs: i think we can tackle that next week as the first item
17:18:43 <spot> also, i'll email the cleaned up perl draft to the list
17:18:46 <tibbs> Hopefully we can meet next week.
17:18:53 <spot> if there is no major disagreement, we can vote on it online
17:19:24 <abadger1999> spot: I've updated the draft page with, I think, all of our changes.
17:19:57 <spot> abadger1999: okay
17:20:06 <spot> then maybe we can just finish this one off. :)
17:20:18 <abadger1999> Refresh page, it's saved in mediawiki
17:20:24 <spot> just saw it
17:20:42 * spot is okay with this draft revision
17:21:12 * spot opens a vote on this revision
17:21:13 <spot> +1
17:21:20 <abadger1999> +1
17:21:23 <racor> spot: I will insist on InitialCC.
17:21:27 <racor> -1
17:21:41 <tibbs> You want it twice in the document?
17:21:48 <spot> racor: it's there
17:21:50 <tibbs> Or you don't think it's appropriate at the top?
17:21:58 <spot> racor: and it is _exactly_ the same wording as was present before.
17:22:22 <tibbs> Though, can we fix the "New Package CVS Request" stuff to not refer to CVS?
17:22:43 <spot> racor: if you want to propose an additional change to make the initial CC required as opposed to strongly recommended, now would be the time. :)
17:22:44 <racor> spot: https://fedoraproject.org/wiki/PackagingDraft:Perl#Perl_SIG does not contain any referrence to initial-cc/InitialCC: perl-sig
17:22:58 <spot> "It's common practice to set the Fedora perl SIG mailing list as a member of the initial-cc list for bugzilla. This can be done by adding the user perl-sig to the initial CC list when creating the New Package CVS Request. "
17:23:20 <spot> racor: it is most definitely there.
17:23:41 <spot> tibbs: dropping the "CVS" seems appropriate.
17:23:44 <abadger1999> tibbs: s/CVS?SCM? fixed
17:23:47 <racor> diffing Toshio's perl.txt vs. perl-draft.txt I see, it was removed.
17:23:50 <tibbs> The proper link is https://fedoraproject.org/wiki/Package_SCM_admin_requests
17:23:59 <tibbs> racor: It was moved from the bottom to the top.
17:24:02 <spot> racor: it was not removed, it was _moved_
17:24:08 <tibbs> Honestly, it's there.
17:24:17 <spot> racor: hit reload on https://fedoraproject.org/wiki/PackagingDraft:Perl#Perl_SIG
17:24:29 <spot> and look at the second sentence in that section. :)
17:25:34 <geppetto> I'm +1 on the current URL
17:25:40 <tibbs> +1 from me.
17:26:08 * spot is still +1
17:26:11 <racor> spot:... better but no cigar. Too little emphasize on perl-sig
17:26:29 <tibbs> It's... the same language as before.
17:26:31 <spot> racor: it is the same text we have had for... oh, 3 years now, at least? :)
17:27:12 <spot> If we change "It's common practice to" to "New perl packages must"
17:27:18 <spot> would that be satisfactory?
17:27:46 <abadger1999> (-1 must ; +1 should)
17:28:35 <racor> spot: It has never been a must ... proposal "should" ?
17:28:43 <spot> should is fine.
17:28:51 <spot> "New perl packages should"
17:29:04 <racor> then ... +1 on this proposal
17:29:25 <spot> i am still +1 with that change
17:29:32 <tibbs> +1
17:30:31 <geppetto> +1
17:30:41 <abadger1999> +1 still
17:30:47 <spot> okay, thats +5
17:30:55 <abadger1999> That's five.. rdieter you can vote for the record.
17:31:26 <rdieter> +1
17:31:32 <abadger1999> Last things before we go -- does anyone want to kick any of these to fesco?  They all seemed non-controversial.
17:31:49 <spot> #action Revised draft (with documented cleanups and changes) approved: 6 +1, no 0, no -1.
17:31:54 <abadger1999> by kick I mean, ask them for review.
17:32:04 * spot doesn't see a need to
17:32:16 <tibbs> Nah, this is all pretty minor stuff.
17:32:18 * abadger1999 also sees no need.
17:32:27 <spot> abadger1999: i just made that last change to the draft text
17:32:34 <abadger1999> Cool.  Just figure we should get into the habit.
17:32:39 <abadger1999> (of asking)
17:32:54 <abadger1999> #topic open floor
17:33:02 <abadger1999> Anyone have anything burning a hole in their pockets?
17:33:08 <abadger1999> If not, we're over time and should end.
17:33:14 <tibbs> Nothing from me.
17:33:22 <spot> nothing that can't wait a week.
17:33:31 <geppetto> Nope
17:33:40 <abadger1999> Alrighty.  Same time next week guys.
17:33:50 <spot> #endmeeting