From Fedora Project Wiki

Fedora Packaging Committee Meeting 2009-04-14

Present

  • Dominik Mierzejewski (Rathann)
  • Jason Tibbitts (tibbs)
  • Rex Dieter (rdieter)
  • Tom Callaway (spot)
  • Toshio Kuratomi (abadger1999)
  • Xavier Lamien (SmootherFrOgZ)

Regrets

  • Denis Leroy (delero)
  • Hans de Goede (hansg)
  • Ralf Corsepius (racor)

New guidelines

Spot mailed out a long notice of new and changed guidelines: https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00806.html There's little point in repeating it here.

Votes

The following proposals were considered:

Other Discussions

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

  • Environment modules
  • Meeting time (again)

IRC Logs

* spot is here 12:08
spot sorry. :) 12:08
* Rathann is here too 12:08
* SmootherFrOgZ is here 12:09
spot abadger1999, rdieter_ ? 12:09
abadger1999 hi 12:09
spot well, thats 5. 12:10
spot Lets try to knock this one out first: 12:10
spot https://fedoraproject.org/wiki/User:Ianweller/WordPress_plugin_packaging_guidelines_(draft) 12:10
tibbs +1 although I wish someone had commented on the possibility of a shared plugin directory. 12:11
abadger1999 +1 12:11
SmootherFrOgZ +1 12:11
spot +1 12:12
SmootherFrOgZ did we get additional info about wordpress and wordpress-mu sub-dir ? 12:12
SmootherFrOgZ or the warning is enough ? 12:13
Rathann the spec template should contain a sample changelog entry, but that's minor 12:13
spot yeah, i don't disagree with that 12:14
Rathann +1 too 12:14
abadger1999 SmootherFrOgZ: what was the additional info? Whether there could be a shared directory? 12:14
abadger1999 I'm betting that that would require patches to the wordpress and wordpress-mu code to look in multiple directories. 12:15
SmootherFrOgZ abadger1999: correct 12:15
Rathann a shared dir could potentially save us half the disk space and half the metadata occupied by wordpress(-mu) plugins 12:15
Rathann granted, it might not be much, but every bit counts 12:16
Rathann so it'd be nice to have 12:16
spot seems like a worthwhile suggestion for ian to make to upstream (maybe even with a patch ready), but not something to hold up this draft. 12:16
spot With +5, it passes 12:16
spot Next item: http://fedoraproject.org/wiki/Common_package_names_packaging_guideline_draft 12:16
spot the cleanups resolved all of my concerns about this one. 12:17
spot so it gets a +1 from me 12:17
tibbs Something went really wrong with some of the formatting. 12:18
abadger1999 yeah.. .fixing formatting 12:18
abadger1999 Formatting fixed. 12:19
SmootherFrOgZ abadger1999: thx 12:19
SmootherFrOgZ btw, +1 from me 12:19
abadger1999 Just the two pre boxes that appeared in the list. 12:19
abadger1999 +1 from me. 12:20
spot Rathann, tibbs? 12:21
tibbs I'm not sure I understand the phrase "Conflicting package names MUST be resolved as there's no way for us to set a Conflicts: tag for the package name." 12:22
Rathann +1 from me 12:22
tibbs Isn't the point simply that we can't have two packages with the same name? 12:23
Rathann tibbs: where do you see that phrase 12:23
tibbs Down at the bottom. 12:23
Rathann I don't see it 12:24
Rathann ahh hold on 12:24
tibbs Also, it looks like something was dropped directly after that phrase; after the period is a lower case "you". 12:24
Rathann it seems it was just edited 12:24
tibbs Also, should we worry about package names differing only in case? Because you know that someone will eventually "rename" by changing the case of a letter. 12:25
Rathann right, it should say that Packaging Guidelines forbid us from using Conflicts: 12:25
abadger1999 Rathann: Except they don't :-( 12:25
spot tibbs: ick. 12:26
tibbs I think that's happened already. Didn't repoview have a problem with package names differing only in case recently? 12:26
abadger1999 Packaging Guidelines currently reads: "Fedora strongly discourages using Conflicts: to resolve these cases." 12:27
Rathann abadger1999: in general they do, there are only very specific cases when it's allowed 12:27
abadger1999 tibbs: Yeah. 12:27
spot "Just as files can conflict, package names can as well. Conflicting package names MUST be resolved. Package names which differ only in case are still considered to be conflicting. You should follow the Same basic steps outlined in #Approaching_Upstream" 12:28
spot how about that wording instead? 12:28
abadger1999 Fine with that. 12:28
Rathann seems fine to me 12:28
tibbs That seems OK. 12:29
tibbs Do we really want to obscure the mailing list address? 12:29
abadger1999 I'm fine either way... I think I saw precedent somewhere but I'm sure I can find precedent the other way as well. 12:29
spot i don't care, it is moderated against non-subscribers 12:30
Rathann hm... speaking of conflicts, why isn't the use of alternatives or environment-modules mentioned in the conflict resolution guidelines? 12:30
spot unintentional omission. 12:30
Rathann because as it is, we couldn't have exim, postfix, etc. in Fedora together ;) 12:31
tibbs Because that would lead people into a space where we have no guidelines. 12:31
abadger1999 Actually, I think alternatives was removed at some point. 12:31
Rathann right, we're about to change that too ;) 12:31
spot feel free to submit another draft to update that section. :) 12:31
Rathann sure 12:31
spot lets vote on the amended Common package names draft 12:32
Rathann if nobody beats me to it 12:32
spot (i made the change in the wiki for the new wording) 12:32
abadger1999 Alternatives is only useful in a few isolated cases... environment-modules is useful much more often but much less known. 12:32
spot +1 12:32
tibbs +1 12:32
abadger1999 +1 12:33
SmootherFrOgZ +1 12:33
Rathann +1 12:33
spot okay, thats everyone at +5. it passes as amended. 12:33
spot next item: https://fedoraproject.org/wiki/PackagingDrafts/UsingAlternatives 12:33
spot Rathann: there is a minor bug in your example 12:34
Rathann I've edited it a bit just before the meeting to better spell out what they are, when to use them and when environment-modules may be better 12:34
spot touch %{_bindir}/antlr should be touch %{buildroot}%{_bindir}/antlr 12:34
*** rdieter_afk is now known as rdieter. 12:34
Rathann right, fixing 12:34
* rdieter is back 12:35
spot also, in the sendmail example 12:35
spot you have: Requires(post): %{_sbindir}/update-alternatives 12:35
spot but it is actually calling %{_sbindir}/alternatives 12:35
tibbs I don't think there's any point in mentioning "environment-modules" when we have no documentation as to what on earth they are. 12:36
abadger1999 Should when "When to use alternatives" Also say that drop-in replacements must be commandline compatible? 12:36
Rathann spot: one is a link to the other but I'll fix 12:36
tibbs abadger1999: Well, in general that's rather difficult. 12:36
abadger1999 Yeah, we need to document environment-modules... 12:37
* abadger1999 remembers nirikexpressing an interest in that long ago. 12:37
tibbs Exim, Postfix and Sendmail support vastly different command line options, yet there's some expected set that they all agree on. 12:37
spot tibbs: yeah, i think we should hold off on mentioning environment-modules until we have it documented 12:37
Rathann abadger1999: I'd think that "drop-in replacement" implies that 12:38
Rathann ok, I'll remove the env-mods reference 12:38
abadger1999 I'm just remembering people wanting to use alternatives in totally inappropriate situations. 12:38
spot it is also worth noting that the MPI implementations seem to use alternatives 12:39
abadger1999 Like /usr/bin/editor => Both something that should be user driven and something that was not commandline compatible. 12:39
spot which is given as your example of when not to use alternatives. :) 12:39
abadger1999 spot: No... they use environment-modules. 12:39
abadger1999 At least, openmpi does. 12:39
spot openmpi does not. 12:39
Rathann spot: the MPIs used to use them, but they were fixed some time ago 12:39
spot i have the spec file open in front of me, i was working on bringing it current before the meeting 12:40
tibbs "should function with sufficient similarity that users and other programs would, within reason, not need to know which variant is currently installed" or something. 12:40
* nirik notes that environment-modules are for things that are a per user choice of a number of installed packages. alternatives is a per system choice where the sysadmin makes that decision. 12:40
Rathann nirik: that's more or less what I wrote in the guideline :) 12:40
abadger1999 Oh ***, what did dledford do to this 12:40
* nirik nods, just mentioning it... I will be quiet. ;) 12:41
tibbs You cannot reasonably partition the problem space into those two possibilities. 12:41
tibbs Java, for instance. 12:41
tibbs Since it's either a system component, or an end user choice, depending on how you look at it. 12:41
Rathann java has a baggage of tradition 12:41
tibbs Perhaps, but that's not the issue. 12:41
spot ha! so true. :) 12:41
Rathann but IMHO we should treat it as any other compiler/language now 12:42
tibbs Even if you ignore the tradition, you still have the same issue. 12:42
tibbs And how do we treat other compilers? They have different executable names. 12:42
Rathann java = the latest version and maybe compat-java-oldversion for older versions 12:42
tibbs You only wish you could do that. 12:43
tibbs The people who care about Java will know when they need Sun java installed. 12:43
Rathann heh 12:43
Rathann isn't sun java essentially the same as openjdk now? 12:43
spot imho, it would be good to see something like nirik's summary about when to use alternatives included 12:43
Rathann but we're veering off topic 12:43
tibbs I think we have to gloss over the Java problem. 12:44
spot as it is still not entirely clear to me which specific situations are proper for me to use alternatives 12:44
Rathann spot: I can collapse when to use and when not to use sections into one and it'll read like what nirik wrote 12:44
abadger1999 spot: If you have to question, it's not appropriate ;-) 12:44
tibbs Except to make sure that whatever guideline we come up with doesn't get some user complaining to the Java folks that whatever they do violates guidelines. 12:44
spot abadger1999: well, i would say what openmpi is doing is fine, for example. 12:44
abadger1999 spot: that depends... as dledford explained it on the mailing list, it's doing it wrong. 12:45
spot yes, but why? 12:45
abadger1999 spot: But he also said that he was using environment-modules (or perhaps I misunderstodd and he was moving from alternatives to env-modules) 12:45
abadger1999 He explained that the end-user needs to make the choice about which mpi implementation is used. 12:46
spot there are multiple packages that provide an mpi compiler with the same set of binary names. they are drop in replacements for each other. 12:46
spot why is alternatives not the solution to that? 12:46
abadger1999 that makes it not a sys-admin choice. 12:46
spot okay. 12:46
abadger1999 end-user can't choose the mpi compiler with alternatives. 12:46
Rathann spot: it is a solution, but not the best one 12:46
nirik because you can't do different ones on the same host 12:46
abadger1999 They can with environment-modules. 12:46
spot okay. 12:47
nirik you may have a cluster where some users want one, some the other, and with alternatives the sysadmin decides and users can't use any of the non preffered ones easily. 12:47
spot i see how the draft makes that distinction, just had to wrap my head around it 12:47
tibbs I think that we need everything below "How to use alternatives" regardless of the other issues. 12:48
spot I'll +1 the whole thing. 12:48
spot it would be nice to see an environment modules draft soon. :) 12:49
Rathann ok, merged the use/don't use sections and added tibbs' suggestion 12:49
Rathann +1 from me, obviously :) 12:50
abadger1999 +1 12:51
spot tibbs, rdieter, SmootherFrOgZ ? 12:51
SmootherFrOgZ +1 including tibbs's comment 12:51
tibbs +1 12:51
rdieter +1 12:51
spot okay, it passes 12:52
spot thats the last item i have on today's agenda 12:52
tibbs Meeting time. 12:52
tibbs What are we to do? 12:52
spot oh yeah. we couldn't find a time that worked for everyone 12:52
spot every time sucks for someone 12:52
spot short of holding two meetings (which i do not wish to do), i'm not sure we can find a better time than what we have now 12:53
tibbs So what can we do? 12:53
* Rathann is fine with current time 12:53
tibbs Do we need a committee that can actually meet? 12:53
spot i'm inclined to leave it as is, with apologies to racor. 12:53
tibbs But we're losing Hans as well, aren't we? 12:54
spot hmm. 12:54
SmootherFrOgZ tibbs: correct 12:54
tibbs I'm not sure about Denis. 12:54
SmootherFrOgZ sometimes he can make it and other not 12:54
spot denis hasn't been here in quite some time 12:55
spot maybe we should try to discuss this further on the mailing list 12:55
tibbs Hans didn't accept either the current time or the proposed time. 12:55
spot trying to do this on irc just gives me a headache 12:56
tibbs One issue I see is that we have folks who joined the committee knowing what time it met and knowing they couldn't make it. 12:56
rdieter esp since the folks we need the most input from aren't here 12:56
spot it would be good to get a range of acceptable dates and times from each member 12:56
abadger1999 It looks like hans can go later, though. 12:56
spot then see where the least number of people are inconvenienced 12:56
spot we do not need to meet here, we can always make a custom channel for our meetings 12:57
Rathann +1 12:57
abadger1999 #fedora-packaging! :-) 12:57
Rathann heh 12:57
spot tibbs: can you send out an email requesting that information from everyone? 12:57
tibbs But then we still have to be mindful of conflicts between other meetings that committee members would need to attend. 12:58
spot (this feels like so much deja-vu) 12:58
tibbs Well, we tried and failed once. It costs nothing to try again. 12:58
spot tibbs: yes, but i would hope members would not list those times and days as available. :) 12:58
SmootherFrOgZ and give it few days before FESco 12:58
spot for example, the Fedora Board meeting that should be happening in 4 minutes. i wouldn't list that time as available on Tuesdays. :) 12:58
abadger1999 If this is going to the list, I have a quick question. 12:59
abadger1999 mono won't currently build against a dynamic libmono.so but will build against a static libmono.a. libmono is built by the mono package. 12:59
* spot throws up in his mouth a little bit 13:00
abadger1999 Do people feel that violates the guidelines? 13:00
spot won't anything else that builds against libmono.so have the same problem? 13:00
tibbs I don't see how "no other alternative" violates the guidelines in general. 13:00
abadger1999 I'm about to make that comment in the bug report. 13:00
abadger1999 At the moment, I don't think we have anything in the distro to test against. 13:00
spot well, if there is really no other alternative... 13:01
abadger1999 Also, this only affects ppc. 13:01
spot but that bug should be fixed when possible. 13:01
spot abadger1999: i think it affects sparc too 13:01
abadger1999 but we'd probably make the change for both ppc and x86. 13:01
abadger1999 Oh yes... it may affect sparc... the symptoms are slightly different but occur in the same place. 13:01
abadger1999 (sparc is spinning at that spot in the build taking a lot of CPU to do nothing. ppc is getting a stack overflow) 13:02
spot i would say that we'll always have disgusting corner cases. The guidelines are not meant to be a barrier to temporary fixes. 13:03
spot assuming that such hacks are indeed, temporary. 13:03
abadger1999 k. I'll say it can do so but we have to work on fixing it. 13:03
SmootherFrOgZ nod 13:03
abadger1999 I'll even threaten that F12 can't have this. 13:03
mbonnet abadger1999: how is the mono build using the just-build libmono.so? Is it setting LD_LIBRARY_PATH or something? 13:03
Rathann just put a comment saying that this violates the packaging guidelines, fixme asap etc. 13:04
Rathann so it doesn't get lost ;) 13:04
abadger1999 mbonnet: Hmm.. god question. (I should stop making assumptions that anything about mono is sane) 13:04
abadger1999 *good 13:04
mbonnet abadger1999: yeah, if it's dynamically linking against the installed libmono.so instead of the just-built version, I could certainly see that causing errors. 13:05
dgilmore abadger1999: :) its clearly not 13:05
abadger1999 mbonnet: Yeah... but not on x86 and x86_64? that would be fishy too. 13:05
abadger1999 Hmm... it uses libtool. so it's quite possible it's using the just-built libmono. 13:06
mbonnet abadger1999: fishy, but not unheard of. We've had cases of dyn-linking between versions of nss work on x86 and segfault on ppc before (was a long-standing mock problem) 13:06
spot well, feel free to discuss this, but i think we're done with FPC business. 13:07
spot thanks everyone. :) 13:07
abadger1999 <nod> 13:07
spot oh yeah, i did all the pending writeups this morning 13:07
abadger1999 mbonnet: I'll give you the answer on #fedora-devel as soon as I untangle the Makefiles. 13:07
spot and announced it to fedora-devel-announc 13:07
spot in case you live in a cave. :) 13:07
SmootherFrOgZ spot: ha :), thx 13:07
Retrieved from "https://fedoraproject.org/w/index.php?title=Packaging:Minutes/20090414&oldid=96992"