Packaging:Minutes/20090303

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:

• ExplicitRequires
  • http://fedoraproject.org/wiki/PackagingDrafts/ExplicitRequires
  • Accepted (6-0)
  • Voting for: abadger1999 spot Rathann tibbs racor rdieter

• Troublesome Source URLs
  • https://fedoraproject.org/wiki/Troublesome_source_URL_packaging_guideline_draft
  • Accepted ( - )
  • Voting for: tibbs spot rdieter Rathann abadger1999
  • Voting against: racor

Other Discussions

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

• https://fedoraproject.org/wiki/Common_package_names_packaging_guideline_draft

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