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