Packaging:Minutes/20090303

From FedoraProject

Jump to: navigation, search

Contents

Fedora Packaging Committee Meeting 2009-03-03

Present

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

Regrets

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

Votes

The following proposals were considered:

Other Discussions

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

IRC Logs

spot abadger1999, racor, rdieter, tibbs, SmootherFrOgZ, Rathann: ping 11:03
tibbs Yo. 11:03
Rathann I'm here. 11:03
racor pong 11:03
rdieter Yo yo 11:03
abadger1999 pong 11:03
spot okay, with me that makes 6 11:04
spot i don't see hans or delero 11:04
spot lets go ahead and get started 11:04
spot tibbs, which guidelines were approved by FESCo? 11:05
tibbs Honestly I'm not sure. I can't generally sit in on their meetings. 11:05
abadger1999 Everything except ExplicitRequires. 11:05
spot everything? 11:05
spot including the stuff from 02-17 ? 11:05
abadger1999 They also hadissues with the Comment Non Obvious Stuff, but accepted it. 11:05
abadger1999 ExplicitRequires was 2-17, right? 11:06
spot ExplicitRequires is listed as 01-20 11:06
spot 2-17 is PHP, Epoch, Icon Cache, DuplicateFiles 11:06
spot  %global too 11:06
abadger1999 Ah. Well, the link in the FESCo ticket was to the message that had both meetings listed. 11:07
abadger1999 I remember a question about %global specifically. 11:07
* nirik notes for anyone looking that fesco is meeting in special session over in #fedora-meeting-1 for features. 11:07
spot okay, so we'll consider them all in writeup, except for ExplicitRequires 11:08
spot which nicely bring us to our next item: PackagingDrafts/ExplicitRequires 11:08
tibbs What do we need to change? Or should we consider dropping it? 11:08
f13 so we had a recent example of foul language in rpm changelogs, does the FPC want to say anything about that, or is that already verboten in some rule? 11:09
f13 oh darn, sorry I thought it was open floor. 11:09
spot tibbs: i think it has been edited already to meet what FESCo wanted 11:09
spot yes. so, basically, we're voting on what you see now at PackagingDrafts/ExplicitRequires 11:10
spot it has been restricted to library Requires 11:11
tibbs My vote doesn't change; even weakened, it's still a useful guideline. 11:11
abadger1999 Yep. 11:11
spot same here. 11:11
abadger1999 +1 11:11
spot +1 11:11
Rathann +1 11:11
tibbs +1 11:11
racor though I consider the new wording to be a regression, it's better than nothing: +1 11:12
rdieter +1 11:12
spot okay, thats +6, it passes 11:12
tibbs Should we try to understand why FESCo insisted on the weakened guideline? 11:12
spot it would be nice to have that feedback 11:13
* Rathann agrees 11:13
spot it might be in the FESCo meeting log 11:13
abadger1999 notting wrote up some information on the Talk page. 11:14
spot okay. lets move on to the next item: https://fedoraproject.org/wiki/Troublesome_source_URL_packaging_guideline_draft 11:14
spot this is documenting existing good practice, seems like a no-brainer to me 11:15
tibbs People keep asking about this, so it seems reasonable to have a guideline about it. 11:16
tibbs +1 11:16
spot +1 from me 11:16
rdieter +1 11:16
Rathann +1 11:16
racor How about making hosting on fedorapeople mandatory? 11:16
spot racor: even when the upstream isn't the packager? 11:16
abadger1999 +1 11:17
tibbs I don't know if it would be productive to copy things to fedorapeople and then copy them again to the lookaside. 11:17
spot i see this as covering the case of "upstream's url doesn't play well with rpm" 11:17
racor spot: In all cases, when upstream doesn't provide a directly accessible tarball (SCM etc) 11:17
spot the scenario of "i am upstream, but have no url for my tarball" is a separate one 11:17
tibbs It's not even RPM, really. RPM doesn't actually use the URL field for anything. 11:17
tibbs It's spectool, mainly. 11:18
Rathann tibbs: rpm looks at Source: to get the tarball filename 11:18
Rathann rpmbuild, that is 11:18
tibbs Oh, I see your point. 11:18
tibbs I mean, we could ask the RPM folks for a new tag or something, but I don't think that would be especially productive. 11:19
spot regardless, that's +5. it would be interesting to see a draft to cover the other case ("i am upstream, but have no url for my tarball") 11:19
abadger1999 I think I'd rather see a way to easily get the tarballs out of lookaside than duplicating on fedorahosted. 11:19
racor BTW: the example being used in the proposal also is of doubtful quality. Though the original URL is not directly accessible, mysql is directly accessible on some (most?) of it's mirrors. 11:20
abadger1999 (for the -- upstream is not the packager and does not have a direct link to the package) 11:20
spot racor: it might be worthwhile to make the example generic, to avoid such specific nitpicking 11:20
abadger1999 racor: that depends: 11:21
abadger1999 http://dev.mysql.com/get/Downloads/MySQL-5.1/mysql-5.1.31.tar.gz/from/http://opensource.become.com/mysql/ 11:21
abadger1999 That's the sort of link you get from the canonical web page. 11:21
abadger1999 Which rpm won't parse. 11:21
abadger1999 If you go directly to the mirror, then you can construct the proper URL. 11:22
tibbs So is it better to just use a specific mirror here? 11:22
abadger1999 But you lose part of the verification chain from canonical site to URL that they provide to mirror. 11:22
tibbs Probably not, given the sourceforge example. 11:22
spot i'd rather leave that up to the packager. having this documented covers other, less obvious cases. 11:22
racor tibbs: I don't know - I am only pointing to other work-arounds to this issue. 11:23
racor tibbs: Not having an external URL, IMHO, is the worst amongst many alternatives. 11:23
spot Lets move on to the next item: https://fedoraproject.org/wiki/Common_package_names_packaging_guideline_draft 11:23
tibbs racor: We are requiring an external URL, just not in the Source: tag. 11:24
racor tibbs: URLs in Source:-tags is all what this is about, because this can be automatically processed. 11:25
tibbs I'm afraid that it's not really possible to write a comprehensive guideline for conflicts like this. 11:26
spot tibbs: i'm inclined to agree with you. 11:27
spot that said, this advice is reasonably sane. 11:27
racor spot: would you share this opinion on License-tags? Let's remove this historic ballast from rpm and move it to comments. I guess you will not like it? 11:28
spot racor: umm, i'm not sure the situations are remotely analogous. 11:29
spot the license tag doesn't take a URL. rpm doesn't try to parse it at all 11:29
spot we have very very good documentation on what is and is not acceptable in the license tag 11:30
spot also, at no point did i or anyone else refer to the URL in the source tag as "historic ballast" 11:30
racor spot: it is. URL/source-tags are technically processable, License-tags are, comments are not 11:30
spot i think we all agree there is value in including the full upstream URL whenever possible. 11:30
Rathann racor: if there's no upstream URL, there's no additional value in providing an URL pointing at some random site 11:31
spot this is only for the situations in which it is not possible due to upstream obfuscating the download path 11:31
Rathann *if there's no upstream URL that can be parsed by rpmbuild, that is 11:31
racor OK, I give in - You want to see Source-Urls regress into something meaningless, so be it. 11:32
spot racor: your dissent is noted in the logs. :) 11:33
spot lets look at https://fedoraproject.org/wiki/Common_package_names_packaging_guideline_draft 11:33
tibbs Such comments are not remotely productive since they're not remotely true. Is it possible for you to restrain yourself? 11:33
tibbs spot: I agree that the advice is sane. 11:33
Rathann racor: you can't put something like http://foo.com/tarball.tar.gz?blah=something in the source url, so you put it in a comment and put the tarball filename instead 11:34
tibbs I could go for this if we really want to wade into the issue. 11:34
Rathann you wouldn't be able to verify it automatically anyway 11:34
spot i think that if i tried to write policy around package naming conflicts, this would be about what I would write. 11:35
tibbs Unfortunately the real issue revolves around the meaning of "generic". 11:36
spot yeah. that is true. we could have two packages call themselves SuperAwesomeDB 11:36
abadger1999 <nod> 11:37
spot and i wouldn't say that is generic 11:37
tibbs The issue which comes to mind is hylafax. 11:37
racor tibbs: And I disagree with you. FPC has just nixed and nullified Source-tags 11:37
tibbs There are three different hylafax packages out there. 11:38
spot What about if we change the first line from: "It is bad practice for a package to use a name that could conflict with other utilities. For instance, "trash" is a bad name to choose because it is so generic that other packages could easily pick the same name." to simply "It is bad practice for a package to use a name that is likely to conflict with other utilities." 11:39
abadger1999 That change is fine with me. 11:39
spot take generic out of the picture, and change it to the likelyhood of conflict 11:39
tibbs Yes, that makes sense. 11:39
tibbs Also, this skirts the hard issue. The package name is easy; things like executables aren't so easy. 11:40
Rathann <nod> 11:41
abadger1999 True... the executables would have to be renamed as well. 11:43
abadger1999 Maybe should add that explicitly in there. 11:43
spot I think if we're going to go this far, we should. 11:43
spot but that probably belongs in the Packaging:Conflicts section 11:43
spot not the naming section 11:43
tibbs Indeed. So do we want to table this until we can do the whole thing, or do we want to vote on just this part first? 11:44
abadger1999 Right. We probably want this in the Conflict Guideline with a link to it from the Naming section if we do that. 11:44
abadger1999 Let's table it. I can work on it this week. 11:44
spot okay. sounds good to me 11:44
* halfline gets back from lunch 11:45
spot next item is: https://fedoraproject.org/wiki/Packaging:FontsSpecTemplate 11:45
spot i'm not entirely sure what the deal is here... 11:45
tibbs We have a redirect in the guidelines that leads to a page which says that it's obsolete. 11:46
spot where is the redirect? 11:46
tibbs Can we just get rid of the redirect? 11:46
tibbs That page is the redirect. 11:47
tibbs Try https://fedoraproject.org/w/index.php?title=Packaging:FontsSpecTemplate&redirect=no 11:47
spot oh. yeah. nuke the redirect. 11:47
spot easy enough. 11:47
abadger1999 Did we approve a template? 11:48
abadger1999 Should we have imported something there? 11:48
spot no, the templates live somewhere else now 11:48
tibbs Is that actually wise? 11:48
spot honestly? i'm not losing sleep over it. 11:49
tibbs I mean, we have some templates in the guidelines, some outside the guidelines and some in fedora-rpmdevtools. 11:49
spot if we have problems with people monkeying with the spec templates, we can pull them in at that time 11:49
tibbs Seems reasonable. 11:50
spot so, thats all the items i see on today's agenda 11:50
spot the floor is now open for any other items 11:51
spot i know f13 had a burning item that just couldn't wait earlier, perhaps he'd like to raise it again? ;) 11:51
f13 yeah 11:51
f13 there was an instance of a changelog with profanity in it. Is this something that is covered by an existing guideline 11:52
f13 or is it something we as a project should concern outselves with? 11:52
spot f13: i'm assuming you're not referring to my "turd" comment, right? 11:52
f13 given that changelogs are displayed in various places. 11:52
tibbs Probably not a packaging guideline, but a code of conduct thing. 11:52
f13 spot: no, the term was "fucker" 11:52
spot well, i agree with tibbs. this is a code of conduct matter 11:52
f13 - caused by some fucker turning on python bindings. 11:52
f13 do we have a code of conduct? 11:53
spot nope. but that sort of thing is FESCo land. 11:53
f13 ok, fair enough 11:53
spot f13: which package was it? 11:53
* spot wonders if he was that fucker 11:53
f13 no, the fucker in question was nirik 11:53
tibbs Fucker. 11:53
* stickster trying hard not to spit-take. 11:53
f13 the package was thibault-fonts 11:53
f13 the change was in fontforge I think 11:54
spot well, i asked nirik to do it 11:54
spot so indirectly, i am that fucker. 11:54
f13 the author of that changelog entry was asked a few time sto change it, and stated that he did 11:54
abadger1999 All problems lead back to spot :-) 11:54
rdieter Fucker 11:54
f13 it now says: - caused by some f***er turning on python bindings. 11:54
rdieter tibbs: that's fun 11:54
tibbs Isn't it? 11:54
rdieter new guideline: don't be a fucker 11:55
* nirik thought he had enabled those bindings before, and it was a good thing to do in any case. ;) 11:55
f13 anywho, I'll toss it at fesco and see what they say. 11:55
spot now that most of us have that out of our system, are there any other items for discussion today? 11:55
racor It now also says: "Edited to censor to fit the whining nature of Fedora PC Freaks." 11:55
tibbs There's a difference between saying "fucker" and picking a fight with another maintainer. 11:55
nirik perhaps we should take this up with his sponsor? which is abadger1999. ;) 11:55
rdieter calling people Freaks is so much better 11:56
abadger1999 nirik: Yep. Iwa ssent the IRC logs this morning. 11:56
tibbs Banning "fucker" would be PC; asking maintainers to be civil with each other is not within the realm of PC. 11:56
abadger1999 Rathann: Was alternatives ready? https://fedoraproject.org/wiki/PackagingDrafts/UsingAlternatives 11:57
Rathann abadger1999: I'm reformatting it right now 11:57
abadger1999 k 11:57
Rathann it'll be ready in a minute 11:57
tibbs Did I miss that when I wrote the agenda? 11:57
tibbs My apologies if I did. 11:57
abadger1999 tibbs: The status is not listed as ready yet so you did fine. 11:57
Rathann https://fedoraproject.org/wiki/PackagingDrafts/UsingAlternatives 11:58
Rathann how does that look? 11:58
tibbs I do think we need a guideline or at least some documentation about this. 11:58
Rathann I added some explanation of what it's for 11:58
spot the "Existing practice" section is good to know, but it shouldn't end up in the guideline 11:59
Rathann of course 11:59
Rathann just section 3 11:59
nim-nim abadger1999, nirik: this is just how the guy expresses himself all the time 12:00
spot also, i'd like to see the motivation spun into the guideline itself 12:00
tibbs Was it decided that using %ghost was the best way to handle this? 12:00
tibbs I didn't follow the entire mailing list thread. 12:01
abadger1999 Rathann: a files section with %ghost probably should be in the sendmail example 12:01
abadger1999 Well... rdieter and I were for %ghost and no one spoke negatively about it. 12:01
spot it seems logical to me 12:02
tibbs I guess I just wonder how rpm handles multiple packages %ghost-ing the same file. 12:02
rdieter I've used that method myself for in-house pkgs before, worked well 12:02
rdieter tibbs: like any other file owned by multiple pkgs, the contents have to match (ie, the convention as outlined is to use 'touch' to create a blank/empty file) 12:02
spot it might be good to include the "touch" section in the spec example to make that crystal clear 12:03
rdieter yes 12:03
Rathann explanation added 12:05
racor How about /etc/alternatives? Is there any way to bring them under rpm-control? 12:05
racor pardon, I was referring to /etc/alternatives/* 12:05
Rathann racor: speaking of which, wouldn't they be better placed under /var ? 12:05
Rathann after all, they're not config files and they're volatile 12:06
rdieter racor: that's an implementation detail of alternatives, that I'd tend to think be best outside the scope of rpm packaging 12:06
racor Rathann: They are "config-links", so ... 12:06
tibbs They're sort of config.. symlinks. 12:06
Rathann hm 12:07
Rathann sort of ;) 12:07
spot Rathann: i like the rewording 12:07
spot we should handle the /etc/alternatives/* similarly to the binary links if feasible 12:07
Rathann right 12:08
racor rdieter: aren't we discussing "best practices" on packaging alternatives? so far, they add unowned entries, ... 12:08
Rathann racor: that's what I'm trying to fix ;) 12:08
spot well, i am hungry. can we revisit this next meeting? :) 12:08
tibbs Well, the packages don't add the entries directly; the alternatives system does. 12:08
rdieter but it depends on how alternatives internal implementation works. 12:08
Rathann spot: of course 12:09
rdieter tibbs: +1 12:09
Rathann I should have it ready by next meeting 12:09
abadger1999 So -- add the touch invocation; Add %files section to sendmail example. 12:09
spot okay, great. good progress, i look forward to it 12:09
abadger1999 Figure out /etc/alternatives/* 12:09
Rathann right 12:09
* rdieter thinks mucking with /etc/alternatives/* is a bad idea here 12:10
spot rdieter: mucking with them, maybe. having them show up as owned by the package? i think thats sane. 12:10
rdieter who maintains alternatives? I suppose if we could get some sort of guarantee that implementations aren't likely to change in the foreseeable future... 12:10
tibbs I guess the point is that the filenames in /etc/alternatives/ are only an implementation detail of the alternatives system; the packager shouldn't know or care what those links are named. 12:11
spot keeping in mind that our guidelines are fluid, and if alternatives changes, we can adapt. 12:11
rdieter tibbs: +1 (again) 12:11
tibbs The problem then is that if alternatives changes, it's not just the guidelines that have to adapt. 12:11
tibbs Of course, there may be no chance in hell of alternatives changing; I don't know. 12:12
rdieter it'll force folks using alternatives, to become intimately knowledgable of how alternatives works... but that's not necessarily a bad thing 12:12
Rathann well, not touch /etc/alternatives is no change from what we have currently 12:12
Rathann and the main problem that I'm trying to solve here is that packages created unowned files which people would expect to be owned 12:13
Rathann and to be able to query rpm/yum/repoquery for them 12:13
* spot nods 12:13
rdieter Rathann: right, I'd rather take baby steps here, treat /etc/alternatives/ handling later (if at all) 12:13
spot well, lets argue about that in two weeks. :) 12:13
* spot calls the meeting 12:13
spot it is lunch time. thanks everyone. 12:13
Rathann okay, thanks 12:14