From Fedora Project Wiki

Fedora Packaging Committee Meeting 2008-08-26

Members Present

  • Denis Leroy (delero)
  • Dominik Mierzejewski (Rathann|work)
  • Hans de Goede (hansg)
  • Jason Tibbitts (tibbs)
  • Ralf Corsepius (racor)
  • Rex Dieter (rdieter)
  • Tom Callaway (spot)
  • Toshio Kuratomi (abadger1999)


IRC Logs

*** tibbs sets the channel topic to "Packaging Committee Meeting". 12:00
* Rathann present 12:00
* tibbs here 12:00
* spot is here 12:01
racor i am here, have ca. 15 mins time. 12:01
spot racor: thanks for coming 12:02
tibbs rdieter, abadger1999: ping 12:02
rdieter here 12:02
tibbs Anyone else I missed? 12:02
--> delero has joined this channel ( 12:03
abadger1999 here 12:03
delero here 12:03
tibbs That's seven. 12:03
spot we're missing hans and Xavier 12:04
spot but hey, quorum. :) 12:04
abadger1999 Woo hoo :-) 12:04
spot okay, first order of business, the drafts that i sent around via email 12:04
spot some of you voted over email, thanks. 12:04
spot however, some of you did not 12:04
tibbs I saw five sets of votes including my own. 12:05
spot yep. 12:05
* Rathann wonders why the members list link on FPC wikipage points nowhere 12:05
abadger1999 Haskell +1, Lisp: +1, fonts.... I'd like to know if the fonts sig will enforce those if we vote 0. 12:05
spot delero: would you like to vote? 12:06
spot we have votes for everyone else 12:06
Rathann abadger1999: or at least how much work it is to enforce that 12:06
* rdieter just sent email minutes ago, in short, I +1'd all of them (including fonts). 12:06
tibbs Rathann: Probably more damage from the conversion. I keep cleaning things up but there's always something else. 12:06
delero i went over them, +1 for me for all 3 12:06
tibbs There were four. 12:07
Rathann but two were about fonts and related 12:07
tibbs True. But two separate proposals. 12:07
Rathann yup 12:07
spot okay, haskell and lisp clearly pass 12:08
Rathann which is why I should add my vote for font bundles: 0 12:08
spot On the Lisp draft, the following comments were made: 12:08
abadger1999 I like both the font proposals. If the fonts-sig is going to enforce them anyways 9as part of a SIG best practice) then I have even more reason to vote +1. 12:08
spot Needs adding an ASDF system definition file template (or link to syntax). 12:08
spot needs to add an empty %build to his spec template 12:09
tibbs I think the link at the bottom should suffice. 12:09
delero i'm ok with the font bundling proposal as well, +1 from me 12:09
spot my concern around the font bundling proposal is that they were drafted specifically to prevent texlive 12:09
abadger1999 spot: Err... specifically in response to texlive. 12:09
spot yes, rather. 12:10
spot while i think that texlive is a clear exception to that guideline 12:10
Rathann I wonder how much work it would be for texlive packager to adapt texlive to follow that guidline 12:10
tibbs Well, texlive does need cleanup. 12:10
racor my concern is that fonts are being bundled with other sources, whatever the font sig wants doesn't change much about it 12:11
tibbs But it's going to have to evolve in that direction. 12:11
rdieter grandfather'd exception for texlive, +1 (that doesn't mean that efforts to fix it shouldn't happen) 12:11
Rathann if it's doable in reasonable time, then I'd vote +1 on both font proposals 12:11
tibbs I think the "no bundling of fonts" proposal is simply unworkable. 12:11
tibbs If I have a game or something that has a simple bitmap font in its own internal format. 12:12
Rathann hmm 12:12
Rathann good point 12:12
tibbs It's a "font" according to the guideline, but I doubt there's going to be any call to split it. 12:12
spot ok, lets vote on the font bundles proposal first (with an exception for texlive for the time being) 12:12
racor -1 12:13
tibbs -1 12:13
rdieter +1 12:13
spot this is 12:13
abadger1999 +1 12:13
tibbs I also have to wonder why fonts are special here. 12:14
Rathann tibbs: because they can be used by other apps? 12:14
tibbs The arguments work for more than just fonts. 12:14
spot well, to be fair, we don't generally permit multiple software items from multiple sources to live in the same srpm 12:15
abadger1999 tibbs: That's true. I could go for a more general rule. 12:15
racor Rathann: Many files can be used by other apps (shared libs, images, sound, movies ...) 12:15
rdieter tibbs: good point, there's currently a best-practice/unwritten rule already about separate sources => separate pkgs. 12:15
abadger1999 But that doesn't eliminate my +1 for the subset :-) 12:15
tibbs I don't know if everyone saw my suggested alternative. 12:15
rdieter tibbs: please refresh our memory. 12:15
tibbs I would 12:16
tibbs consider it it were distilled to a simple strong suggestion that separate 12:16
tibbs upstream projects not be bundled together in the same package. I 12:16
tibbs believe that's an unwritten rule already. 12:16
spot tibbs: "a simple strong suggestion that separate upstream projects not be bundled together in the same package." 12:16
tibbs But I don't want to derail the current vote. I can write a proposal later. 12:16
rdieter I can totally support that. 12:16
spot i'm much more in favor of that 12:16
Rathann 0 unless a list of font formats to which this guideline is applicable is supplied (+1 then) 12:16
abadger1999 tibbs: I'd love to have that written down rather than unwritten. 12:16
delero strictly enforcing it on existing packages is going to be tough, especially on dormant projects where the fedora packager has become the ad-hoc maintainer 12:17
abadger1999 Although textlive, for instance, has already brought issues up wrt that :-( 12:17
Rathann tibbs has a good point about bundled fonts that could not be used system-wide 12:17
tibbs Enforcing anything on existing packages has always proven difficult. 12:17
delero pstoedit is an example, it ships with an old bitmap font 12:17
abadger1999 as texlive is an upstream but is also a conglomeration of other upstreams, how does the rule apply? 12:17
abadger1999 I don't need that answered now, just saying that question has already been raised. 12:18
Rathann also, it doesn't always make sense to make some obscure fonts (symbol fonts, incomplete fonts) visible system-wide 12:18
spot I think that we should say something like "Fedora packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package." 12:18
rdieter I'd say let's ask for the current bundles draft to strike paragraph 1, pending a more general soon-to-come guideline. 12:19
Rathann so while I agree with the guideline in the spirit, it needs to allow for common sense and not be as strict 12:19
abadger1999 I just got a call. I have an electrician coming out to the house and will have to leave when he gets here. 12:19
delero Rathann: +1 12:19
rdieter Rathann: I read it that way already, it says SHOULD 12:19
Rathann ah 12:20
Rathann right, the last paragraph of clears it up a bit 12:20
Rathann but I'd limit it to what I suggested above 12:21
racor i think paragraphs 2+3 should be striked. They attempt to special case something which isn't a special case. 12:21
Rathann i.e. not only general-purpose formats but general usability 12:21
tibbs rdieter: The Packaging font bundles proposal doesn't seem to say SHOULD. Lots of MUSTs there. 12:21
rdieter I'm reading , which includes MUST only in paragraph 1, which I think we've all agreed needs to be stricken anyway 12:22
spot with two -1, and one 0, there is no way that "Packaging_font_bundles" can pass 12:22
rdieter the only must remaining is the licensing bit, but maybe that's not required hee 12:22
tibbs Email from Xavier: he'll be a bit late. 12:22
Rathann does "packaged separately" mean a totally separate package or can it be a subpackage? 12:22
Rathann hm looks like the former 12:23
rdieter Rathann: I read that as either 12:23
tibbs I read it as "totally separate package". 12:23
racor source or binary package? 12:23
rdieter sorry. context matters. ignore me 12:23
tibbs Otherwise arguments about separate upstream release cycles and such make no sense. 12:23
racor demanding a separate source package is silly 12:23
spot can we vote on adding "Fedora packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package." to the main guidelines? 12:23
rdieter spot: +1 to that 12:23
Rathann spot: +1 12:23
delero spot: +1 12:23
tibbs Will we need to discuss exemptions? 12:24
racor -1, superflous not of any importance 12:24
tibbs Circular dependencies was always an interesting one to me. 12:24
tibbs +1 12:24
spot +1 from me 12:24
tibbs racor: What existing guideline does this duplicate? 12:24
Rathann it may be common sense, but common sense is sometimes most difficult to follow ;) 12:25
spot with a +5, it passes 12:25
spot now, it seems like we might be able to reword the first paragraph of Packaging_font_bundles to make it more sensible 12:25
abadger1999 Would it be better to phrase it as a MUST? ie: any package which bundles multiple separate upstream projects MUST justify that decision? 12:26
racor tibbs: this sentence is a waste of text - whether this sentence is presence or not doesn't change anything 12:26
tibbs I don't follow your argument. 12:26
racor upstreams don't care about what we decide 12:26
racor to new-comer packagers this text is not helpful 12:27
racor it's just bloat 12:27
tibbs It answers a question that has been asked of me several times already. 12:27
tibbs I guess I could simply continue to answer as I wish, but I'd rather have an actual guideline. Which it seems we'll have. 12:27
* rdieter is confused now, this guideline only describes downstream packaging, not much to do with upstreams at all 12:28
racor bring this to attention of major upstream projects - You'll be laughed at. 12:28
Rathann racor: some upstreams start caring when we explain it to them 12:28
spot okay, so, if we replace the first paragraph of Packaging_font_bundles to "As noted in the Packaging Guidelines, Fedora packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package. This applies equally to font packages." 12:28
spot then, leave the rest as is... i think that makes it more reasonable 12:29
racor Rathann: Do you care about SuSE, Debian, Ubuntu, Gentoo packaging desires in packages you are upstream? I don't. 12:29
rdieter I'm still not sure about the "each bundled font set ends up in a different mono-licensed sub-package", that seems to be itching for a generalized rule too, no? 12:29
Rathann racor: nobody laughed at me when I started packaging inchi separately from openbabel and submitted patches to fix building with external inchi 12:29
racor try glibc, try gcc, ... 12:30
spot rdieter: i think it makes some sense to do it that way for fonts specifically, especially if other applications want to rely on a single font 12:30
racor anyway, i've got to quit now, sorry. 12:30
spot they wouldn't need to Requires: foo-superfonts-dump, they could Requires: foo-superfonts-myfont 12:31
rdieter umm... do apps really need to care about the fonts used licensing-wise? 12:32
rdieter if so, doesn't that get very scary, very fast? 12:32
spot rdieter: generally, no, but it does make for a reasonable divisor 12:32
Rathann but licensing is a good reason for splitting packages in general 12:33
Rathann i.e. foo licensed under GPL and foo-libs under LGPL 12:33
Rathann assuming that's what upstream does 12:33
Rathann or foo-someplugin under another license (say, BSD) 12:34
abadger1999 You have my +1 to this. 12:34
abadger1999 Electrician is here, gotta run. 12:34
Rathann I wouldn't put so much stress on packaging fonts separately due to licensing issues, it is a more general thing 12:35
spot take a look at this: 12:35
spot 12:35
tibbs The first MUST there implies that this guidelines is stronger than the general one. 12:36
Rathann doesn't say why, though 12:36
tibbs Is that still the intention, or is this just supposed to be a clarification of the other guideline as it applies to fonts? 12:36
delero this means ONE font per subpackage ? 12:36
Rathann delero: one font family 12:36
spot delero: font family 12:37
* rdieter likes that draft more. happy happy 12:37
spot i think this is a clarfication for fonts 12:37
Rathann well if it's phrased that way, it becomes redundant 12:38
Rathann the first paragraph 12:38
Rathann but +1 too 12:38
delero I assume this would apply to a package like gnuplot, which ships postscripts fonts 12:38
rdieter not this draft, afaict, the other one... maybe. :) 12:39
Rathann delero: but does it make sense to use them outside gnuplot? 12:39
spot well, should we take a vote on ? 12:40
delero Rathann: unlikely 12:40
Rathann I wouldn't want to force any package to split their fonts if it doesn't make sense to use them outside their apps 12:40
spot keep in mind that all reasonable exceptions are okay. 12:40
spot (as always) 12:40
rdieter spot: +1 P_F_B2 draft 12:40
delero spot: +1 on v2 draft 12:40
spot +1 from me 12:40
Rathann +1 on v2 draft 12:40
spot abadger1999: gave us a +1 before he left... tibbs? 12:41
tibbs I guess I don't really understand why it mandates a split by license, but I don't have any real problems with it. 12:42
tibbs +1 12:42
spot tibbs: it doesn't mandate that anymore 12:42
spot i changed it to read "make sure each bundled font set ends up in a different, appropriately licensed sub-package. " 12:42
Rathann rather, splitting by license is a general "should, if makes sense" 12:42
tibbs I've been reloading but I don't see the change. 12:42
Rathann not only with fonts 12:42
spot tibbs: ? 12:42
tibbs I'm still seeing "but he MUST make sure each bundled font..." 12:43
spot note that i made a copy with changes for v2 12:43
tibbs Yeah, I'm looking at v2. 12:43
spot If upstream refuses the packager MAY base a single src.rpm on the collection archive, but he MUST make sure each bundled font set ends up in a different, appropriately licensed sub-package. 12:43
spot old version said "If upstream refuses the packager MAY base a single src.rpm on the collection archive, but he MUST make sure each bundled font set ends up in a different mono-licensed sub-package." 12:44
spot anyways, thats +6 12:44
spot i can't think of a quick way to reword No_bundling_of_fonts_in_other_packages in such a way that it would be acceptable 12:45
spot well, i take that back 12:45
spot maybe if we changed item 1 to 12:45
spot 1. any package that makes use of fonts should strongly consider packaging them in a separate sub-package, if they have any value outside of the package 12:46
rdieter item 2 isn't really a MUST, just a pointer 12:46
Rathann spot: I'm fine with a MUST in your modified version even 12:47
spot yeah, but if it makes people think about font licenses, i'm not opposed to it 12:47
rdieter spot: your version of 1 is a lot better, likey likey 12:48
--> hansg has joined this channel ( 12:48
hansg Hi all 12:48
Rathann also if such font has value outside the application, maybe ask upstream to publish font source separately? 12:48
hansg I just saw spot's invitation 12:48
hansg any votes needed from me, or did we already have the quorum? 12:49
spot hansg: you're not too late, we're just going through the last pending draft 12:49
Rathann hansg: we're discussing 12:49
hansg -1 12:49
spot hansg: we're trying to fix it. :) 12:49
Rathann <spot> maybe if we changed item 1 to 12:49
Rathann <spot> 1. any package that makes use of fonts should strongly consider packaging them in a separate sub-package, if they have any value outside of the package 12:49
hansg For reasons already mentioned 12:49
Rathann well? any comments on my suggestion? 12:50
spot 12:50
spot take a look at that 12:50
spot Rathann: i'm on the fence as to whether it should be a "SHOULD" or a "MUST" 12:51
spot i can see both sides of that argument 12:51
spot (i'm leaning towards a must, as a sub-package) 12:51
Rathann spot: no, I mean the other suggestion ;) 12:52
Rathann I said I was fine with either should or must here 12:52
spot oh yes, that is good, i'll add it 12:52
hansg Hmm, just read Spot's draft I dunno what to think of this 12:52
Rathann hansg: it's just the 1st point that's different 12:52
Rathann I think that was the main contention 12:53
hansg All in all it seems well balanced between making clear that generic fonts must be packaged separately and that specials could be bundled 12:53
hansg I would like to see some language in here about how this all applies only to fonts in font format. 12:53
Rathann "fonts in font format"? 12:54
tibbs Think back to my earlier question. 12:54
Rathann hansg: the last paragraph is not enough? 12:54
hansg Games often package fonts as just a bmp which when you lay a 64x64 grid over it you get each letter 12:54
Rathann ah 12:54
Rathann then the first solves it 12:54
hansg or on XxX format for that mayyer 12:54
spot okay, i added Rathann's suggestion: 12:54
spot hansg: if i made it say "bundled font files" 12:55
spot would that be more appropriate? 12:55
spot or "bundled fonts (in font format)" 12:55
hansg I'm not sure about the "any value outside of the package " wording, that is a bit vagu 12:55
hansg vague I mean 12:56
hansg Spot, +1 for "bundled font files" 12:56
hansg That is better IMHO 12:56
hansg And maybe we should replace the "any value outside of the package " wording by a list of formats and a MUST be in a subpackage if in one of these formats 12:56
Rathann hansg: it's not just formats 12:57
Rathann it's also the usability 12:57
hansg For example if a game has some special font created for it in ttf, it would be good to put it in a sub package so that it can be used more general 12:57
hansg (assuming the licensing is ok) 12:57
hansg Rathann, explain 12:57
Rathann it doesn't make sense if such font contains just a limited subset of characters or symbols which is usable only in that game 12:57
rdieter hansg: but "good" for who? if no one can/will ever use it? 12:58
Rathann hence it also needs to be usable outside the original application 12:58
hansg Rathann, ah yes 12:58
hansg rdieter, will never use it just a matter of advertising, can never user it is another story 12:58
spot how about something like "especially if the font is in a standardized format, and contains a set of characters or symbols which are useful for other packages." 12:58
hansg Ok, lets stick with the "any value outside of the package " 12:59
hansg spot +1 12:59
hansg (although that violates the less is more principle) 12:59
spot it does, and i think the "any value outside of the package" is actually broader. 12:59
hansg I'm fine with keeping just "any value outside of the package " 13:00
* Rathann is fine with either 13:00
Rathann obviously some people need explaining the spirit of the rule ;) 13:00
Rathann so more precise language won't hurt IMHO 13:01
spot how about this 13:01
spot 13:01
spot i added it as a clarifier 13:01
tibbs Seems OK to me. 13:02
Rathann yup 13:02
delero excellent 13:02
tibbs I wonder whether we're still within the spirit of the original draft which was submitted. 13:02
spot well, we'll hear back for sure if we're not. 13:02
spot i think we are 13:02
hansg spot, good, about font source, its that mandatory, or does it depend on the font license? 13:02
Rathann I think so too 13:02
Rathann we just added some common sense ;) 13:02
spot hansg: not sure i follow 13:03
Rathann hansg: you mean the point about asking upstream to publish font source separately? 13:03
Rathann it's not mandatory 13:03
hansg Well if someone designed a font for project X and gave project X just the .ttf file and a license to do whatever they want with the ttf, there will be no font source 13:03
spot how about i change that to just "font files" 13:04
spot not "font source" 13:04
spot to eliminate confusion 13:04
Rathann yes 13:04
Rathann that's what I meant 13:04
hansg spot, hmm yes and no 13:04
hansg We do want the preferable format for modification when available 13:04
<-- delero has left this channel. 13:05
spot hansg: yes, but thats a licensing issue 13:05
Rathann the idea is that generally useful fonts should migrate to separate packages alltogether 13:05
Rathann hence my suggestion to ask upstream to publish font files 13:05
hansg spot again yes and no, it can be that we don't need the font "source" from a license pov, that doesn't mean we don't want it if available 13:05
spot by not specifying, we can safely assume we want source 13:06
hansg true 13:06
spot 13:06
spot it now says "font files" on that line 13:06
spot guys, i need to dash off to the board meeting 13:06
spot can we vote on this quickly? 13:06
Rathann hansg: but isn't that is already in font packaging guidelines? 13:06
rdieter spot: +1 to v2 13:07
spot +1 from me 13:07
hansg +1 13:07
Rathann hansg: "Fonts SHOULD be built from source whenever upstream provides them in a source format" 13:07
tibbs +1 13:07
Rathann +1 from me 13:07
spot do we have quorum? delero dropped... 13:07
hansg Rathann, we should add: "if upstream does not provides them in a source format, the packager should contact upstream and ask them to provide source if possible" 13:07
spot wait, that is +5 13:07
spot ok, it passes. 13:07
hansg yes thats enouh, right?? 13:08
spot and with that i have to go to the board call 13:08
Rathann hansg: that is fine by me 13:08
spot thanks guys 13:08
Rathann thanks spot ;) 13:08
* hansg wonders why my typing is even lousier then normal 13:08
spot i'll update the todo page this afternoon 13:08
tibbs I will try to get minutes out today; with the FESCo move, we have no way to make their 24 hour deadline. 13:09
hansg well that was short (for me) when is the next meeting? 13:12
Rathann hansg: we should discuss the possible times and choose one that works well for everyone if possible, current one was difficult for me until recently 13:17
hansg Didn't we try that by using a wiki page were we all wrote down what worked, and then failed? 13:18
Rathann and I won't know until next week if it continues to be 13:18
tibbs The problem seems to be that there's always some kind of conflict. 13:18
abadger1999 tibbs: FTR, I'm +1 to spots revised fonts guideline. 13:33