From Fedora Project Wiki

< Packaging:Minutes
Revision as of 20:29, 17 February 2009 by Tibbs (talk | contribs) (New page: === Fedora Packaging Committee Meeting 2009-02-17 === ==== Present ==== * Denis Leroy (delero) * Dominik Mierzejewski (Rathann|work) * Jason Tibbitts (tibbs) * Ralf Corsepius (racor) * R...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Fedora Packaging Committee Meeting 2009-02-17

Present

  • Denis Leroy (delero)
  • Dominik Mierzejewski (Rathann|work)
  • Jason Tibbitts (tibbs)
  • Ralf Corsepius (racor)
  • Rex Dieter (rdieter)
  • Tom Callaway (spot)
  • Toshio Kuratomi (abadger1999)
  • Xavier Lamien (SmootherFrOgZ)

Regrets

  • Hans de Goede (hansg)

Writeups

There are no new guidelines this week.

Votes

The following proposals were considered:

  • User Creation
    • Somehow during the wiki conversion a guideline page was created that redirected too a draft page. This was in error; FPC never approved the draft and the redirection page has been removed.

Older Business

The following three drafts from the previous meeting await FESCo

Other Discussions

  • There was some discussion relating to the ReviewGuidelines document in the wake of the failure of the ReviewGuideline_for_fonts document to pass for a second time. abadger1999 drafted https://fedoraproject.org/wiki/User:Toshio/Type_Specific_Guidelines as a strawman, and spot indicated that he plans to put additional work into ReviewGuidelines. There was also discussion of moving it out of the Packaging namespace and handing it over to the Package Review SIG, but that SIG has yet to develop fully.

IRC Logs

*** spot sets the channel topic to "FPC Meeting: https://fedoraproject.org/wiki/Packaging/GuidelinesTodo". 11:10
* spot looks around to see who is here 11:11
spot i see rdieter, tibbs, and me 11:11
tibbs racor was here a bit ago. 11:11
spot abadger1999, racor, Rathann, SmootherFrOgZ 11:11
Rathann present 11:11
* abadger1999 here 11:11
racor here 11:11
spot delero is coming 11:12
--> delero has joined this channel (n=denis@192.18.8.1). 11:12
spot so, we're just missing hans and SmootherFrOgZ 11:12
tibbs I have not seen Xavier since fudcon. 11:12
spot that should be enough to get started 11:13
spot well, i saw him at FOSDEM, but I didn't actually talk to him about FPC 11:13
abadger1999 SmootherFrOgZ has been busy but around. 11:13
spot item 1: https://fedoraproject.org/wiki/Packaging/UserCreation 11:13
spot i can't find any record of us approving this one 11:13
* kanarip is here 11:14
Rathann spot: I noticed that there's a newer version: https://fedoraproject.org/wiki/PackageUserCreation 11:14
tibbs And the page doesn't exist at all in the old wiki as far as I can see. 11:14
abadger1999 <nod> I was pretty sure we approved Villa's method instead 11:14
* SmootherFrOgZ is here 11:14
SmootherFrOgZ what's up tibbs 11:14
tibbs FPC meeting.... 11:14
spot well, we should either approve it or take it out 11:14
SmootherFrOgZ k 11:14
spot "Using 'fedora-usermgmt' is optional and not required by packaging guidelines." 11:15
spot I'm inclined to remove it from the guidelines based on that sentence alone. 11:15
tibbs I'm confused as to how this page even got into Packaging. 11:15
tibbs I don't believe it should be there at all. 11:15
spot that would make two of us. 11:15
Rathann spot: +1 to that 11:15
abadger1999 spot: +1 11:16
spot i wonder if someone didn't take advantage of the wiki changeover here... 11:16
tibbs According to the redirect page history it was imported from moin twice, and them mmcgrath changed it. 11:16
spot okay, i see +4 to removing it 11:16
tibbs http://fedoraproject.org/w/index.php?title=Packaging/UserCreation&action=history 11:16
spot anyone else want to toss in a vote to remove it? 11:16
racor +1 remove it 11:17
rdieter +1 11:17
spot okay, thats +6. out it goes. 11:17
spot Next item: https://fedoraproject.org/wiki/PackagingDrafts/global_preferred_over_define 11:17
spot it seems fairly straightforward 11:18
abadger1999 Ville proposed this a long time ago. It has tripped a few people up from time to time. 11:18
Rathann spot: +1, though a lot of people will keep using %define because they're used to it 11:18
abadger1999 I don't see any drawbacks 11:18
rdieter looks good to me, +1 11:18
tibbs This actually seems sane, but there are templates and other guidelines which will need changing. 11:18
Rathann maybe add an rpmlint check? 11:18
delero +1 here 11:18
abadger1999 Yeah, I'll run through and change them 11:19
spot okay. 11:19
tibbs I don't see a reason for any existing package to change unless it's broken. 11:19
spot +1 from me 11:19
abadger1999 guidelines that is. 11:19
tibbs +1 11:19
spot tibbs: agreed 11:19
abadger1999 +1 11:19
SmootherFrOgZ +1 from me 11:19
racor +1 11:19
tibbs But packages which supply RPM macros and such should all be changed. 11:19
spot wow. been a while since everyone agreed on anything. ;) 11:19
abadger1999 <nod> 11:19
spot i will take that as a good omen. ;) 11:19
abadger1999 That will be a pain point. 11:19
spot next item: https://fedoraproject.org/wiki/PackagingDrafts/ReviewGuideline_for_fonts_%282009-01-22%29 11:20
rdieter tibbs: how so? 11:20
tibbs rdieter: Well, they should use %global because of the issues laid out in the draft we just approved. 11:20
tibbs spot: Did that page get updated? It wasn't when I wrote the agenda. 11:20
rdieter tibbs: packages that supply macros, are /etc/rpm/macros.* , or are you talking about something else? 11:21
spot tibbs: yes, it was edited yesterday 11:21
tibbs rdieter: Yes, that's what I'm talking about. If they don't use %global, they really should. 11:21
rdieter tibbs: they don't use define or global, the syntax is different 11:21
tibbs Oh, never mind then. 11:22
rdieter :) 11:22
tibbs spot: I fail to see what in that draft we didn't discuss last time. 11:22
tibbs It just adds a discussion section. 11:22
Rathann it's good as a temporary measure until something like abadger1999 is proposing can replace it 11:23
abadger1999 https://fedoraproject.org/wiki/User:Toshio/Type_Specific_Guidelines 11:23
abadger1999 What I'm proposing. 11:23
Rathann yup 11:23
abadger1999 I still don't like it. 11:23
Rathann abadger1999: why? it seems reasonable to me 11:23
abadger1999 if people aren't following the current guidelines WRespect to fonts, it could be that they are missing them in the sea of rules. 11:24
spot the biggest concern is that reviewers (for better or worse) use that page as a checklist 11:24
abadger1999 Just adding to the sea of rules may help with fonts (or may not) but will definitely make things harder for everyone. 11:24
abadger1999 If it's got new information, then I'm for it... but it seems to just reiterate current info. 11:24
* spot is on the fence here 11:25
rdieter nod, can't follow the rules, because they're too big and hard to follow, so let's add another one. 11:25
spot i don't see the harm in adding it, but i would like to get rid of that page. 11:25
spot i'm inclined to freeze that page as is and instead work on making it obsolete 11:26
tibbs spot: By that page you mean ReviewGuidelines? 11:26
spot tibbs: yessir 11:26
rdieter spot: +1, I'm on the fence too, but adding it short term is ok, long-term find something better 11:26
tibbs I kind of like the idea of a footnoted checklist without further explanation. 11:26
spot tibbs: that's pretty much what it is now 11:27
tibbs Many reviewers find it useful. 11:27
rdieter useful yes, authoritative it is not, how to make that clearer 11:27
rdieter ? 11:27
tibbs Without it they really have nothing, but I wouldn't object to moving it somewhere else. 11:27
spot okay. if we're treating Review Guidelines like that, we should A) add this line and B) go through the guidelines and make it complete 11:27
tibbs I had proposed a package review sig item to discuss trying to take responsibility for that page. 11:28
spot tibbs: did they have any interest? 11:28
tibbs Unfortunately the last call for participation I put out only received one comment. 11:28
tibbs So I'm not sure if the review sig really exists right now. I'll just try again. 11:29
spot okay, well, in the interim, i'm inclined to simply add it 11:29
tibbs Still, moving it under PackageMaintainers might not be a bad idea in any case. 11:29
spot it isn't wrong, and it is useful for reviewers to know 11:29
tibbs Or whatever the new wiki-friendly name is now. 11:29
kanarip ;-) 11:29
spot unlike other type specific packages, fonts can show up inside any package 11:29
spot (i caught two of them in a package i was making this morning) 11:30
abadger1999 I'm -1 but I'm not overly concerned... it's just one more on top of the existing mess. 11:30
spot +1 from me 11:30
spot i'm also going to try to rework that page into a summary checklist form 11:30
spot (i will draft it before i commit it) 11:30
spot so, i see +2 and one -1 11:31
Rathann 0 from me 11:31
rdieter +1 11:31
delero -1 here 11:31
racor -1 11:31
spot okay, it fails. 11:31
spot Next item: https://fedoraproject.org/wiki/PackagingDrafts/PHP 11:32
tibbs What exactly were we voting on, for the minutes please? 11:32
spot as before, I still don't understand PHP. 11:32
rdieter moving the page, will have the added bonus of not being locked, so it could get more love. 11:32
* RemiFedora here if needed 11:32
spot tibbs: adding the item to review guidelines 11:32
tibbs Ok, so we just voted on the same thing we voted on last week. 11:32
laubersm tibbs: wiki-friendly: something like Review guidelines for packaging with 11:32
spot tibbs: yep. 11:32
tibbs Anyway, my -1 to that for the record 11:33
tibbs PHP was late; I didn't get a chance to read the new draft. 11:34
spot there is a diff here: https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FPHP&diff=78843&oldid=78835 11:34
tibbs BTW, the draft says "Fedora Extras". 11:35
spot yeah, thats a minor issue. ;) 11:35
spot i will fix that if we approve it 11:35
tibbs There are also some minor grammatical issues, which aren't a big deal but which will need fixing. 11:36
spot given that this is already being used in packages, and nothing in it seems to be harmful or obviously incorrect 11:36
spot tibbs: i can get those too 11:36
spot +1 from me 11:37
rdieter +1 , may the php gods have mercy on our souls 11:37
SmootherFrOgZ +1 from me 11:37
abadger1999 +1 11:37
tibbs +1 11:37
delero +1 11:37
racor 0 11:37
tibbs It wasn't really bad last week; it just needed a bit of clarification which is there now. 11:37
spot okay, thats +6 11:38
Rathann +1 11:38
spot it passes 11:38
spot sorry, +7. ;) 11:38
spot next item: https://fedoraproject.org/wiki/PackagingDrafts/Epoch 11:38
racor IMO, all these provides: foo() each need to be explained. 11:38
tibbs racor: Explained how? Do you mean justified to this committee or explained with comments in the spec? 11:39
racor I was referring to the php proposal. They are adding further pollution to the rpmdb without explaining it 11:39
tibbs OK, is it possible for one channel package to provide php-channel(foo) and php-channel(bar)? 11:40
delero epoch use to transition from third-party repos ? what third-party repos are we talking about here ? 11:40
racor we already have too much of such stuff in rpm, hardly anybody understands the precise meaning 11:40
abadger1999 Not specified in guideline. The scenario that brought this up was planet ccrma 11:40
rdieter delero: an example was a pkg that was being imported from... ccmra (?) 11:41
racor This epoch proposal is effectively granting everybody the right to introduce arbitrary epochs. 11:41
Kevin_Kofler PlanetCCRMA and plenty of others. 11:41
spot For what it is worth, i agree with this draft. 11:41
rdieter delero: but the guideline is to allow safe migration of users from 3rd-party repos to fedora 11:41
tibbs I prefer to leave Epochs up to the maintainer. 11:41
spot When it is possible for us to not pee in other peoples cornflakes, we should do so. 11:41
Kevin_Kofler Also my CalcForge repo which has some Epoch 1 packages for various historical reasons, which I will want to merge into Fedora eventually. 11:42
racor It doesn't limit the source but explicitly says: either privately or publicly accessible repository 11:42
Kevin_Kofler tibbs: That's what lkundrak's proposal (the one which is being voted on) effectively does. 11:42
spot If the package maintainer has a good reason for an epoch that they can document, then I think it is permissable. 11:42
tibbs It has a "must not" in it. 11:42
spot One of my packages has an epoch for that very reason. 11:42
tibbs "If you use an epoch, please indicate why you are using it." 11:43
Kevin_Kofler It doesn't make sense to introduce a new package with Epoch >0 if it's not in some other repo. 11:43
rdieter shrug, this guideline is just common sense to me, and I usually don't like codifying that... but... +1 11:43
racor spot: Reason: I am using Epoch: 42 in my local repository - This is nonsense 11:43
tibbs That's really all I think is needed, although somewhere there should be an indication of what problems epochs can cause. 11:43
Kevin_Kofler I think this is what lkundrak is trying to say with that must not. 11:43
spot well, we could strike the "private" repo part from it 11:43
Rathann we should 11:43
spot yeah, that part is the only odd thing in the draft 11:44
racor If at all, we should restrict introducing epochs to a precisely defined list of repos 11:44
Rathann IMHO only public repos with significant userbase should be considered, not just any publicly available repo 11:44
abadger1999 It's a little verbose for me but I agree with the "Here's some ideas for when to use epoch, maintainer decides how to apply them" 11:44
spot i really do not want to start saying which repos are acceptable and which are not 11:45
spot i'd rather leave it up to the packager's best judgement 11:45
Kevin_Kofler racor: The proposal doesn't require you to match the Epoch (as the one I originally wrote did - for the record, I didn't submit it officially and won't do that if lkundrak's proposal passes), but it says you should use common sense. So if the repo uses Epoch: 42 just to test the rules, that's not going to fly. 11:45
spot if it shows up in a public repo, and the packager wants to ensure a clean transition with an epoch, they should be free to do so 11:45
Rathann Kevin_Kofler: how is it not going to fly? all it takes is one sloppy reviewer and insistent packager 11:46
racor spot: defining this list is the point. Otherwise we are opening the gates for everybody to flood fedora with obscure epochs. 11:46
delero do we have some sort of ideas how many epochs this will introduce ? 11:46
spot okay, if we did define a list, it would have to be a very permissive one. 11:46
Kevin_Kofler Defining the list does not make sense. New repos may come up. 11:46
Kevin_Kofler And their goal is not to force Epochs into Fedora. ;-) 11:46
Rathann Kevin_Kofler: they should be approved by FPC then, IMHO 11:47
racor delero: A carelessly maintained repos could introduce arbitrary epochs 11:47
delero Kevin_Kofler: I'd rather see thsi as a "grandfather" rule 11:47
Kevin_Kofler It's usually to quickly package stuff for testing without going through formal review. 11:47
spot yeah, i really think the goal here is to encourage these items to come into Fedora from third party repos 11:47
delero spot: how often is this the primary reason a package is not transitioned into Fedora ? 11:47
spot and if the users of those third party repos can't cleanly update to the new Fedora package, then we've not really given them any incentive. 11:47
spot delero: well, at least one notable case in recent history. :) 11:47
Rathann spot: rpm -e oldpackage ; yum install fedorapackage 11:48
delero spot: which one ? 11:48
Kevin_Kofler There will be more when I'll care to submit the TiLP stack. 11:48
spot Rathann: and if that package is a library? or higher up in the depchain? 11:48
Kevin_Kofler The versioning scheme changed at one point, so the whole stack has Epoch 1. 11:48
spot (unlikely, i admit, but still) 11:48
rdieter spot: the incentive part is big... we really need this, imo. 11:49
Rathann spot: that's one of the rare cases when --nodeps comes in handy (with --justdb, possibly) 11:49
spot i think we need something here, even if it is common sense. 11:49
Kevin_Kofler Rathann: Speaking as one of the affected repo maintainers, telling our users to manually reinstall packages is not going to fly. 11:49
Rathann I don't like allowing arbitrarily high epochs 11:49
Kevin_Kofler If you want me to submit the TiLP stack into Fedora, it needs to keep that Epoch 1. 11:49
tibbs Why can't we just discourage epochs and require documentation of any that are present? 11:50
rdieter more common sense? crazy talk. 11:50
tibbs Any attempt to legislate which repos we can inherit epochs from is doomed to failure and arguments. 11:50
spot well, honestly, with the "private" wording dropped, i'm inclined to +1 the draft 11:50
Rathann I'm for example annoyed at our java maintainers for having jumped to 1.7.0 and then to 1:1.6.0 11:50
tibbs Sure it's annoying, but what were they supposed to do? 11:51
tibbs And what does the epoch really hurt, anyway? 11:51
delero Rathann: well mistakes are unavoidable. I think that's a valid use of epoch, as a last resort to fix a problem... 11:51
racor rdieter: IMO, it would be common sense to disallow new packages with Epoch, because fedora has no possiblity to take arbitrary el-freako 3rd party repos into account 11:51
spot Basically, this draft sums up the key points in my mind: 11:52
spot 1) Brand new Fedora only packages, no epoch. 11:52
Kevin_Kofler Rathann: What else should they have done? Sun released 1.7 devel code first, but then the IcedTea project decided to focus on 1.6 instead. 11:52
spot 2) Packagers don't have to use epoch if they don't want to. 11:52
abadger1999 epoch does mean you have to remember to use it in, say, Requires: but it's not like we can ignore epochs just because they're not often used. 11:52
spot 3) If the package is being imported from a public repo and that outside package has an epoch, you can use it to keep a smooth transition. 11:52
kanarip can i mention a side note here? 11:53
tibbs kanarip: We welcome comments. 11:53
kanarip ruby-shadow was in fedora, is unmaintained, a new ruby-shadow is coming up, lower version number... brand new package but i'm gonna need to use epoch 11:53
Rathann spot: 2) Packagers must not use epoch unless there's no other way. 11:53
kanarip so, what i'm basically saying is, "brand new" could use a little clarification 11:53
Kevin_Kofler IMHO that should be s/being imported from/present in/. 11:53
delero Unfortunatley I have to run here. For the record, I'm voting -1 11:54
tibbs Rathann: "other way" could just mean lying about the version, which is far worse then Epoch:. 11:54
Kevin_Kofler Where the specfile you import comes from is not the issue, the fact that the package is present in the third-party repo is. 11:54
Rathann tibbs: that's not acceptable either 11:54
spot Kevin_Kofler: okay, but we shouldn't expect packagers to be psychic about such things 11:54
racor kanarip: epochs are legitimate for package inside of Fedora, we currently are talking about 11:54
racor introducing package with Epoch: > 0 11:54
rdieter kanarip: nod, a perfect example of where Epoch makes sense, imo 11:54
kanarip racor, like i said....... what i'm basically saying is that "brand new" could use a little clarification..... :/ 11:55
kanarip that's it, i'm not commenting on whatnot 11:55
Kevin_Kofler racor: I still don't see why third-party repos shouldn't be allowed the same kinds of mistakes we allow ourselves (which aren't even always their fault, sometimes it's upstream's). And I'm not the only one. 11:56
tibbs Can we at least get some documentation out that indicates why epoch are so bad? Mailing list traffic isn't really a justification. 11:56
rdieter tibbs: there isn't any => fud. 11:57
rdieter sure, it complicates things, and should be avoided (duh), but that's it. 11:57
tibbs I'm sure there's some. Issues with versioned dependencies are the only thing I know of, though. 11:58
racor rdieter: wrong: rpmver 0:1.0-1 1:0.2-0 => 1:0.2-1 is newer 11:58
tibbs That's like saying "wrong: 1>2" 11:59
racor Now use Requires: xxx > 1.0 11:59
rdieter racor: nod, that's part of what I meant about "complicates things". Not unsurmountable 11:59
tibbs Besides, since an epoch may crop up at any time for legitimate reasons, everyone has to be wary of issues with versioned dependencies. 12:00
rjune Perhaps just some documentation on what epoch is, and how it should be used would be a good first start. 12:00
spot okay, i reworded it somewhat 12:00
spot https://fedoraproject.org/wiki/PackagingDrafts/Epoch#Proposal 12:00
racor rdieter: conclusion? Mine: avoid epochs unless impossible. 12:01
rdieter rjune: hint: if you don't know what an epoch is, don't use it. :) 12:01
rjune rdieter, not valid, people will use what works for them, regardless of actually understanding why. 12:01
rdieter rjune: I'm not saying documentation isn't welcome, but that's outside the scope of this conversation, imo. 12:02
tibbs spot: I could get behind that. Can we add some sort of documentation requirement or do you think that's too much? 12:02
rjune fair enough. 12:02
spot Well, i'd hate to have people vote this down because it requires a comment 12:02
spot but i'm not opposed to it. 12:02
tibbs It probably falls under the whole "non-obvious" thing anyway. 12:03
racor spot: As long as "either privately or publicly accessible repository" is in: -1 12:03
rdieter maybe vote on both? the proposal as-is, and an ammendment for comment? 12:03
spot racor: i changed it to drop the "private" part 12:03
tibbs racor: That isn't in the draft which was just presented. 12:03
spot now it only refers to public repositories 12:03
rjune spot, just to confirm, if the package exists in an official repo. don't use it. if the package exists in a non-official repo but is now going into an official one, use some forethought in whether to apply epoch? 12:04
spot rjune: ehh... 12:04
rdieter forethought is good either way... 12:04
Rathann rjune: don't use epoch unless you have to 12:04
spot rjune: more like "don't use epoch unless you have to." 12:04
* Rathann smiles at spot 12:04
spot can we vote on the draft as is? if it passes, we'll vote on amending it to require a comment 12:05
rjune then say so. There are valid uses for epoch. Generally for private repos overwriting a base package or major version scheme changes. 12:05
racor spot: Ok, much better now, however I consider the sentence starting with "In the event that ..." to be superfluous 12:05
rdieter spot: +1 to the draft 12:06
Rathann racor: +1 12:06
rjune +1 12:06
spot +1 from me 12:06
SmootherFrOgZ +1 12:06
tibbs +1 12:06
spot I see +4 for the draft... 12:06
abadger1999 +1 12:06
spot okay, thats +5. 12:07
abadger1999 Is this line necessary, though? 12:07
abadger1999 In the event that the Epoch tag is not present in the third-party package, the packager can include an Epoch under the same circumstances under which he would include the Epoch tag in the Fedora package such as the change of the versioning scheme. 12:07
tibbs I don't really think so. 12:07
racor spot: scratch the redundant sentence, until then -1 12:07
spot i can drop the line 12:07
spot it doesn't change the guideline 12:07
abadger1999 <nod> 12:07
spot the packager would still be permitted to use the epoch as that line describes 12:08
abadger1999 Right. 12:08
racor ATM: here, https://fedoraproject.org/wiki/PackagingDrafts/Epoch#Proposal displays to old contents?!? 12:08
spot racor: you must have a cached copy 12:08
spot would it change anyone's vote if i took that line out? 12:09
rdieter not I 12:09
spot not me 12:09
tibbs Not I. 12:09
spot SmootherFrOgZ? 12:09
SmootherFrOgZ not 12:09
racor spot: sorry, reloading doesn't help 12:09
spot okay. i will drop that line now. 12:09
rjune if I count, not me either. 12:09
abadger1999 +1 either way 12:09
spot racor: https://fedoraproject.org/wiki/PackagingDrafts/Epoch 12:10
spot okay, it passes as is 12:10
spot (with the line dropped) 12:10
spot should we do a vote on whether to add a comment requirement upon use of epoch? 12:11
tibbs I'm starting to think it isn't needed. 12:11
tibbs Especially if the "non-obvious" draft was accepted; I can't remember. 12:12
spot okay. we can always add it later if we find it is needed. 12:12
spot abadger1999: was the non-obvious draft accepted by FESCo? 12:12
Rathann spot: +1 12:12
abadger1999 FESCo ran out of time for reviewing the FPC minutes. 12:12
abadger1999 :-( 12:12
spot okay 12:12
abadger1999 It's feature season. 12:12
tibbs Two weeks in a row? 12:12
spot well, we're at an hour or so now 12:12
SmootherFrOgZ a comment could be usefull to check if the packager knows what is actually doing 12:13
spot we can keep going through the agenda or adjourn now 12:13
rdieter keep going 12:13
spot okay, lets try one more item 12:13
tibbs I'm not going anywhere. 12:13
spot Next item: https://fedoraproject.org/wiki/PackagingDrafts/Icon_Cache 12:13
spot this got a lot of discussion on the list 12:14
tibbs I was going to suggest refraining from doing this kind of thing until skvidal could work out the stuff he was talking about at fudcon. 12:14
spot %posttrans scares me a bit, but still. 12:14
tibbs But I don't know if that's progressing. 12:15
spot Otherwise, I'm +1 here. 12:15
abadger1999 I think it was pretty straightforward. Even %posttrans isn't too big a departure in this case. 12:15
Rathann %posttrans doesn't work for erasure, but I see that's taken care of by keeping it in %postun 12:15
tibbs We know that this works across the full spectrum of rpm and yum versions that Fedora supports? 12:15
spot i'm pretty sure it does. 12:16
abadger1999 We'll jsut have to watch for other people wanting to use %posttrans inappropriately in their Snippets. 12:16
rdieter +1 here 12:16
Rathann spot: even EPEL-4? 12:16
spot Rathann: well, EPEL is used to this sort of thing 12:16
spot but yeah, i'm pretty sure posttrans works there 12:16
spot and if it fails, its not a big problem 12:16
<-- delero has left this server (Read error: 110 (Connection timed out)). 12:17
spot the cache just doesn't get updated 12:17
Rathann ok then, +1 12:17
tibbs What does this actually help? Or is it just opening the way for further optimization by RPM? 12:17
SmootherFrOgZ <nod> +1 12:17
abadger1999 +1 12:17
spot tibbs: having the cache updated is good, and this minimizes the number of times the cache is updated in a transaction 12:17
abadger1999 It is a minor optimization (%posttrans allows filesystem cache to make the update-icon-cache calls much faster) 12:17
rdieter tibbs: it should help a lot 12:18
spot We're at +5 here. 12:18
tibbs +1 12:18
abadger1999 And makes the scriptlet more robust (addition of :) 12:18
abadger1999 err... : 12:18
tibbs I can't see how this could change the number of times gdk-update-icon-cache would actually be called, though. 12:18
* abadger1999 hates smileys 12:18
--> delero has joined this channel (n=denis@AMontsouris-156-1-146-51.w83-202.abo.wanadoo.fr). 12:18
abadger1999 Correct. 12:18
tibbs I can fully understand the cache effect, though. 12:18
abadger1999 Same number of times. Just caching. 12:18
spot okay. one more, just to push my luck. 12:18
spot Next item: https://fedoraproject.org/wiki/PackagingDrafts/Duplicate_Files 12:18
rdieter tibbs: # of times is the same, but they'll skip rebuilding because the touch'es in between are skipped now 12:19
tibbs rdieter: Ah, that does seem significant. 12:19
tibbs spot: This draft effectively renders illegal the R Jones's insistence on including the license files multiple times. 12:19
abadger1999 So this one is still getting worked over on the list. 12:20
abadger1999 tibbs: I'd argue that that's technically not allowed now. 12:20
abadger1999 But maybe we want to allow it? 12:20
tibbs abadger1999: It's unclear, I guess. We've been allowing it. 12:20
abadger1999 That's kind of what the list discussion is about. 12:20
tibbs Personally I would rather not allow it, as we have too many damn copies of the GPL already. 12:20
spot my only concern is that such duplication inflates the install footprint needlessly 12:21
spot i think if you want every package to pull in the license, you can make a -common or -docs package that owns the license 12:21
tibbs I really like the idea of just picking which subpackage a file should be in, putting it there, and being done with it. 12:21
spot and then have all the other packages depend on it 12:21
tibbs Only the weird mechanics of %doc render it simple to duplicate the license file. 12:21
Rathann maybe we could put all license texts in their own packages and just Requires: license-foo = version in the main package? ;) 12:22
spot Rathann: *barf* 12:22
Rathann ... guess not 12:22
spot there are so many different license texts with different copyrights 12:22
spot i'd be doing nothing but committing license texts to cvs all day 12:22
tibbs I'll go on record as +1 for this draft now. 12:22
tibbs spot: But you could do the common ones.... 12:22
spot tibbs: yes, but i'd have to be super vigilant that i didn't miss a common one which was edited 12:23
spot i'd rather just be safe and let each package carry a copy of its own 12:23
spot fwiw, I'm +1 here, with the understanding that like all guidelines, if there is a good exception to be made by the packager, so be it. 12:24
tibbs It would be interesting to see a valid exception. 12:24
tibbs I'm having trouble making one up that a -common package doesn't solve. 12:25
tibbs Maybe if -common would be one file or something. 12:25
spot tibbs: me too, but i'm not omniscient (yet) 12:25
abadger1999 yeah, the list discussion just says "making a -common for a few files is not desirable" 12:25
spot anyone else want to vote here? 12:25
rdieter +1 12:25
SmootherFrOgZ +1 12:25
abadger1999 +1 12:26
Rathann +1 12:26
spot that is +6 12:26
spot it passes 12:26
abadger1999 I'll write in something about gathering exceptions to the Guidelines page. 12:26
spot i'm pretty sure the other two items on the agenda aren't ready for voting 12:26
abadger1999 ie, let us know what exceptions exist. 12:26
abadger1999 Yep. 12:26
spot thus, the floor is open for any other topics 12:26
abadger1999 One's being talked about with docs, the other is... problematic. 12:26
tibbs Was the agenda I posted useful? 12:27
spot tibbs: extremely, thank you. 12:27
SmootherFrOgZ tibbs: yes 12:27
abadger1999 tibbs: +1 thanks for doing that 12:27
Rathann tibbs: very much, thanks 12:27
tibbs I will post another before the next meeting. 12:27
tibbs If anyone has any suggestions, please let me know. 12:28
spot okay, if there is nothing else, i'll close out the meeting. 12:28
Rathann I'm slowly working on some guidelines for using alternatives, I'll send them to the list for comments 12:28
spot i'm going to try to work on an improved version of ReviewGuidelines too 12:28
Rathann because currently it's free-for-all and that has some problems 12:28
spot i will send out a draft when it is ready for comments 12:28
laubersm I'm working on wiki renaming and categories - comments welcome at 12:29
laubersm https://fedoraproject.org/wiki/Docs_tasks_for_Packaging_Guide_and_related_materials#Packaging_Guide_Drafts 12:29
spot Rathann: sounds like a good idea. 12:29
SmootherFrOgZ spot: excellent 12:29
spot laubersm: thanks! 12:29
Rathann spot: I'm looking forward to that, they need to be trimmed down 12:29
spot Rathann: heh, i'm not sure you'll like what i make then. :) 12:29
spot but we'll see 12:29
abadger1999 Does anyone have issue with the renamings proposed by laubersm? 12:30
abadger1999 it all seemed good to me. 12:30
spot seems fine to me 12:31
spot well, i'm calling the meeting done. stick a fork in it. Thanks everyone! 12:31
abadger1999 thanks spot 12:31
Retrieved from "https://fedoraproject.org/w/index.php?title=Packaging:Minutes/20090217&oldid=79211"