From FedoraProject

Jump to: navigation, search


Fedora Packaging Committee Meeting 2009-02-03


  • Dominik Mierzejewski (Rathann|work)
  • Jason Tibbitts (tibbs)
  • Ralf Corsepius (racor)
  • Rex Dieter (rdieter)
  • Tom Callaway (spot)
  • Toshio Kuratomi (abadger1999)


  • Denis Leroy (delero)
  • Hans de Goede (hansg)
  • Xavier Lamien (SmootherFrOgZ)


The following drafts have been accepted by FESCO and are to be written into the guidelines:


to address FESCo commentary

Other Discussions

The following additional items were discussed; see the logs for full details.

  • PHP guideline modifications for dealing with channels - PackagingDrafts/PHP
    • FPC requested additional cleanups and clarifications.

IRC Logs

* spot looks around for FPC 11:14
* Rathann|work present 11:14
spot abadger1999, tibbs, racor, rdieter ? 11:16
tibbs Yep. 11:16
rdieter here 11:16
abadger1999 here 11:16
racor here 11:16
spot i don't see anyone else online 11:16
* abadger1999 apparently has an off-by-a-week bug :-) 11:16
spot so i think it is just us 11:17
spot abadger1999: did i get the date wrong? 11:17
tibbs No, this is the right day. 11:17
spot oh, good. 11:17
abadger1999 Just me. 11:17
spot okay, lets get started 11:17
* RemiFedora present 11:17
tibbs I'd be willing to help. 11:17
spot tibbs: that would be a huge help 11:17
tibbs Let's talk about it later. 11:18
spot basically, the PHP people want to standardize naming and packaging of PHP channels 11:18
spot i know practically nothing about PHP 11:18
tibbs I don't really object to it in principle. 11:18
tibbs I think we already have at least one channel package. 11:18
tibbs Four of them, actually. 11:19
RemiFedora we already have 4 extras channels in repository (phing, phpdb, symfony and phpunit). A new one (ezc) is on the road 11:19
spot yeah, i'm inclined to approve this, as nothing appears to be horrifying or awful inside of it 11:19
Rathann|work I don't understand something here 11:19
Rathann|work * CHANNEL packages should be named php-channel-ChannelAlias-%{version}-%{release}.noarch.rpm 11:19
Rathann|work * Packages from another channel should be named php-ChannelAlias-PackageName-%{version}-%{release}.noarch.rpm. 11:19
Rathann|work does the first refer to some channel-common package? 11:20
tibbs For example, a channel package: 11:20
tibbs php-channel-symfony.noarch 11:20
Rathann|work ok, but if pear and pecl follow the same template, why list them separately? 11:20
Rathann|work that confused me a bit 11:21
spot should the naming in the second line be " php-channel-ChannelAlias-PackageName-%{version}-%{release}.noarch.rpm" ? 11:21
RemiFedora If you take a package from "pear" channel it's named php-pear-xxxx 11:21
RemiFedora from pecl channel : php-pecl-xxx 11:21
tibbs I don't think so. That's not a channel, it's a package from the "ChannelAlias" channel. 11:21
spot tibbs: okay 11:21
* spot already admitted that he doesn't understand PHP 11:22
tibbs But that's what PHP folks do, and we should at least figure out how to cope. 11:22
spot i think if anything in here causes problems, we'll hear about it. 11:22
spot also, the PHP folks are pretty good about this in general 11:22
spot so, +1 from me 11:22
tibbs Also, the change in the pear template from Requires: php to Requires: php-common is snuck in there. I think that's a good idea as well. 11:23
Rathann|work I think this proposal needs a bit of cleanup (typos, for example) 11:24
Rathann|work also the phrase "channel package" is confusing 11:24
Rathann|work does it mean "a package from some channel" or "a metapackage for some channel"? 11:24
Rathann|work seems like both, depending on the context 11:24
spot Rathann|work: i'll cleanup typos when i merge it 11:24
tibbs You have to package the channel itself. 11:24
Rathann|work tibbs: yes, I got that 11:25
RemiFedora Rathann|work, an channel package is a repository config file (like fedora-release) 11:25
Rathann|work but for example there's 11:25
Rathann|work A CHANNEL package 'MUST have : ... 11:25
Rathann|work A PEAR package MUST have: 11:25
Rathann|work isn't PEAR a channel too? 11:26
RemiFedora We probably could write : A package from PEAR channel 11:26
RemiFedora And yes, pear is a channel, installed by default (php-pear) 11:26
Rathann|work RemiFedora: we should! ;) the current text is confusing to me 11:26
tibbs I think I would like to see what the final guideline page looks like. 11:27
* Rathann|work too 11:27
Rathann|work as it is, I don't even want to vote on it 11:28
spot RemiFedora: can you rework the draft to make it a bit less confusing? 11:28
RemiFedora yes 11:28
spot alright, we'll table it for now and revisit next meeting 11:28
Rathann|work I mean, any idea to make things consistent gets +1 from me 11:28
RemiFedora but if I put the "final" version, diff will be difficult... 11:28
Rathann|work but it shouldn't be ambiguous 11:28
spot RemiFedora: do your best. :) 11:29
spot Next item: 11:29
tibbs mediawiki makes diffs pretty easy. 11:29
spot basically, nim-nim would like us to add a line to the review guidelines to remind viewers to check for fonts and their legal status 11:29
spot "reviewers", rather 11:29
tibbs How is that different from any other content that reviewers would need to check the legal status of? 11:30
tibbs Poor grammar, that. 11:30
spot How about "MUST: Font files (if any) are packaged according to Packaging:FontsPolicy." 11:31
racor is Packaging:FontsPolicy part of the FPG? 11:31
spot racor: yes... 11:31
spot so, technically, this is redundant 11:31
racor no external documents. 11:31
Rathann|work racor: we have external documents for Perl, Python, Java, ... 11:32
abadger1999 Long term, this needs to be something that docs helps us reorganize. 11:32
racor The point is access to them. I do not want to have us undermined. 11:32
spot racor: they can't edit that page anymore than anything under Packaging/ 11:32
spot Packaging: is the same as Packaging/ 11:32
Rathann|work spot: For fonts, I'd just add a footnote like for Perl/Python/PHP/Java 11:33
Rathann|work no need for fonts-specific line in the guidelines 11:33
abadger1999 short term... I'm a bit ambivalent. redundancy and clutter are just as harmful as too little information when we have too many disorganized Guidelines. 11:33
spot Rathann|work: this is the ReviewGuidelines 11:33
Rathann|work yes, I know 11:34
spot many people are using ReviewGuidelines as the basis for things that they should remember to check on every review (for better or worse) 11:34
Rathann|work that is, -1 for adding this to ReviewGuidelines, +1 for adding at the end of PackagingGuidelines 11:34
tibbs I do believe this is addressing two real problems, and one of them isn't really restricted to fonts. 11:34
spot i think that is why nim-nim wants a specific "check for fonts, make sure you follow guidelines" 11:34
spot technically, everything in ReviewGuidelines is covered elsewhere in the Packaging Guidelines now 11:35
Rathann|work hm, I missed it but it's already there in the Packaging Guidelines 11:35
tibbs So, do we need a mention in the review guidelines relating to any necessary legal checks? 11:36
Rathann|work why are fonts so special that they need an explicit mention in Review Guidelines? 11:36
spot tibbs: we have "MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines ." 11:36
tibbs Rathann|work: I guess because folks keep missing them. 11:36
tibbs spot: That's licensing, I guess. Are there other legal checks? Patents? 11:37
tibbs I don't really know how we can ask anyone to do that, though. 11:37
spot we have to walk a blurry line there 11:37
Rathann|work hmm 11:37
spot the vast majority of reviewers are doing fine in the legal area 11:38
tibbs The problem is that people are using this document and still missing the fonts stuff. 11:38
spot i think that many people might forget to check for fonts and font licensing 11:38
Rathann|work all right 11:38
tibbs So do we evolve the documents to help revieiers not miss things? Or do we pedantically say that it's all in the guidelines, and they should memorize them all? 11:38
abadger1999 I don't like this... OTOH, I think adding something to the review process that helped people find out if they had certain types of files and apply certain Guidelines if they do would be nice. 11:39
Rathann|work but this should be added as a subpoint of MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines . 11:39
abadger1999 that's a more comprehensive document though. 11:39
spot i'm more interested in something like: "MUST: Font files (if any) are packaged according to Packaging:FontsPolicy." 11:39
spot that page has links to the packaging and legal concerns around fonts 11:40
Rathann|work spot: fine... 11:40
Rathann|work although I'd prefer something more general with fonts given as an example of content that needs special checks 11:40
spot longer term, i think there is merit in making ReviewGuidelines extinct, and automating as much of it as possible 11:40
rdieter spot: +1 (to MUST, and long term plan/intentions) 11:40
spot +1 for my proposed MUST 11:41
tibbs Is there a more general notice that would fit? "This document isn't intended to indicate everything that must be checked. Be aware of specific guidelines, such as the font packaging guidelines which must be followed for fonts which may be part of the package." 11:41
rdieter sorry, I've got to leave early in a minute or 2... anything else (quick)? 11:42
spot tibbs: i don't know if it will have the same effect 11:42
Rathann|work i.e. MUST: Any included content must be appropriately licensed. For example, for fonts, see Packaging:FontsPolicy. 11:42
spot Rathann|work: yes, but this is more than a licensing issue 11:42
spot Rathann|work: fonts have to be packaged in a unique way 11:42
Rathann|work alright then, +1 to spot's MUST 11:42
tibbs +1 spot 11:42
abadger1999 rdieter: The Fonts update from last week was rejected by FESCo, but I don't know that we can vote on revisions without discussion. 11:43
spot abadger1999: it was? 11:43
abadger1999 spot: yes. 11:43
tibbs Yes, fesco rejected some things, but I wasn't able to be at their meeting. 11:43
spot the feature? 11:43
tibbs It keeps moving and I keep missing it. 11:43
abadger1999 The one that we split into two parts. 11:43
spot oh hell. 11:43
abadger1999 I'll dig it up after this. 11:43
spot i wrote that up into the guidelines 11:43
abadger1999 Oops. 11:44
* spot apologizes. i hadn't seen them reject anything. 11:44
tibbs Who here is still on fesco? 11:44
tibbs Any of us? 11:44
rdieter heh, I'll be avail on-irc/onilnes later, if votes are needed. my apologies. 11:44
*** rdieter is now known as rdieter_away. 11:44
spot well, one thing at a time 11:45
spot we have +4 for my MUST 11:45
spot abadger1999, racor? 11:45
abadger1999 Oh it wasn't fonts.. it was ExplicitRequires that we split into two. 11:45
racor I am not convinced and prefer to abstain: 0 11:45
abadger1999 -1 11:45
spot okay, at +4 it does not pass. 11:45
abadger1999 I don't think this direction is going to scale. 11:46
spot alright. it is worth noting for the record that the lack of a mention in ReviewGuidelines doesn't mean that reviewers shouldn't check for fonts and be sure they comply with Font packaging guidelines 11:46
Rathann|work abadger1999: when was that last fesco meeting? the log from Jan 16 shows they've approved some fonts guidelines 11:47
spot abadger1999: ExplicitRequires is not written up yet 11:47
Rathann|work abadger1999: 11:47
tibbs Maybe this is something that the package review sig could take up. 11:47
Rathann|work <- this is approved 11:48
spot abadger1999: i don't see any logs or minutes newer than jan 16 11:48
spot i'll poke jon stanley and see what happened to them 11:49
tibbs So, if there is no longer any overlap between FESCo and this group then we need to figure out how we want the communication to work. 11:49
spot thats all i have on today's agenda 11:49
abadger1999 11:50
abadger1999 ExplicitRequires was on their agenda for that meeting and rejected. 11:50
spot okay 11:50
Rathann|work ah 11:50
spot 'need less enumeration into "non-obvious"' ? 11:51
bpepple spot: we started rotating writing meeting summaries, and it looks like not everyone has been putting them on the wiki. :( 11:51
spot they want us to be more vague about what is non-obvious? 11:51
tibbs So much for trying to leave some things to the good sense of the packager.... 11:51
spot does anyone want to take a pass at trying to fix this up for FESCo? 11:52
Rathann|work one would first have to know what the issue was 11:52
abadger1999 So I think that part is basically, take out the list of examples. 11:53
tibbs I have the minutes archived somewhere. Let me dig them out. 11:53
Rathann|work that's a bad move IMHO, examples are necessary 11:53
tibbs Well, not the minutes; the actual log. 11:53
spot i really disagree with that 11:53
abadger1999 Also, I think it wasn't obvious to FESCo that these were now intended to be read as two separate Guidelines. 11:53
spot the examples are necessary 11:53
abadger1999 They brought up rwmjones's comment about FHS and cross-compilers. 11:54
abadger1999 WRT the list. 11:54
tibbs [Fri Jan 23 2009] [11:51:28] <nirik> I'm a bit worried about how vuage the 'Non obvious items' thing is... but ho 11:54
tibbs pefully people will use common sense. 11:54
spot okay, so we can clarify the FHS example 11:54
tibbs [Fri Jan 23 2009] [11:52:39] <notting> -1 to ExplicitRequires, both because non-obvious seems to be overly specifie 11:55
tibbs d, and the ExplicitRequires isn't confined to library dependencies 11:55
tibbs [Fri Jan 23 2009] [11:54:29] <jds2001> so for explicitrequires, I'd like to see a little less guidance on what "non 11:55
tibbs -obvious" means. 11:55
spot perhaps change it to "FHS violations (except for documented exceptions such as libexecdir and cross-compilers)" 11:55
tibbs [Fri Jan 23 2009] [11:57:17] <j-rod> something adding a note about commenting non-obvious stuff that is completel 11:55
tibbs y unrelated to Requires: seems, uh, out of place, on a page titled 'explicitRequires' 11:55
spot why would we want to confine ExplicitRequires to library deps? 11:55
tibbs Looks like they missed the fact that there were two completely separate proposals on one page. 11:55
tibbs Anyway, I think that covers the objections from the log. 11:56
spot so, i think i'd like to try to sell it to FESCo 11:56
spot when is their next meeting? 11:56
tibbs Friday. 11:57
tibbs At least I think it's on Fridays now. 11:57
spot crap. i will be in route to Brussels then 11:57
abadger1999 spot: Friday. Maybe we should take out the FHS entry specifically. 11:57
spot abadger1999: yeah, seems fine to me 11:57
spot is someone willing to help FESCo understand the draft on friday? 11:57
spot Also, please toss in votes for dropping the FHS example 11:58
spot +1 from me 11:58
tibbs My in-laws are in from Norway then; I can't promise to be around then. 11:58
abadger1999 notting also had an objection to the Explicit Requires section not limiting itself to dynamic libraries but no one else followed up on his comment. 11:58
abadger1999 +1 to dropping 11:58
racor +1 to dropping 11:58
spot abadger1999: can i ask you to represent this at FESCo on friday? 11:58
Rathann|work +1 from me as well 11:59
abadger1999 spot: Yeah -- not sure I'll be good at it though. 11:59
abadger1999 I'm willing to make the Guideline very vague. 11:59
spot well, lets see if with explanation, they will approve it 11:59
tibbs +1 dropping the FHS example if that's what it takes. 11:59
spot if not, we'll revisit it and make it so vague it could describe badger mating patterns. 11:59
spot okay, the FHS example is dropped 12:00
spot are there any other issues for today? 12:00
tibbs Meeting agenda. When should it be posted, and where should I take the items from? 12:01
tibbs Maybe Friday previous to the meeting? 12:01
Rathann|work tibbs: not a bad idea, that'd give us time to look it over during the weekend 12:01
spot tibbs: start with Packaging/GuidelinesTodo 12:01
Rathann|work or monday latest 12:01
spot tibbs: and anything you think is agenda worthy from the -packaging list 12:02
tibbs Is GuidelinesTodo sufficiently updated? 12:02
spot tibbs: i generally keep it clean 12:02
tibbs OK, I'll use that. 12:02
tibbs We'll try it in 1.5 weeks.... 12:02
spot okay, thanks! 12:02
Rathann|work thanks tibbs 12:02
spot i think we're done then. thanks everyone. 12:02

Generated by 2.6 by Marius Gedminas - find it at!