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:
- Wordpress plugin guidelines
- Guidelines for conflicting package and executable names
- Guidelines for alternatives
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 |