From Fedora Project Wiki
Fedora Packaging Committee Meeting 2009-06-02
Present
- Jason Tibbitts (tibbs)
- Rex Dieter (rdieter)
- Tom Callaway (spot)
- Toshio Kuratomi (abadger1999)
- Xavier Lamien (SmootherFrOgZ)
Regrets
- Denis Leroy (delero)
- Dominik Mierzejewski (Rathann|work)
- Hans de Goede (hansg)
- Ralf Corsepius (racor)
Votes
The following proposal was considered:
- Phase out BuildRoot:
- https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29
- Accepted (5-0)
- Voting against:
Other Discussions
The following additional items were discussed; see the logs for full details.
- https://fedoraproject.org/wiki/Features/OSGiAutoDeps
- FPC would like to see this formulated as a guideline change (indicating what the guidelines and relevant specfile templates would look like after the change) and not as a feature page.
- https://fedoraproject.org/wiki/Features/BetterRpmAutoReqProvFiltering
- Similarly, FPC would like to see this written up as a guidelines change. FPC is also concerned that there are two separate changes involved there; one provides a filtering mechanism, the other changes the behavior of the perl dependency finder and does not seem to be mentioned in the draft.
IRC Logs
| * spot looks to see what is pending | 12:22 | |
| tibbs | Same as last week, although Chris Weyl had something he was going to send to fesco that is probably more appropriate for us. | 12:23 |
|---|---|---|
| spot | the phase out buildroot thing? I kindof want to do that and the redhat-rpm-macro changes i proposed on -devel at the same time | 12:23 |
| tibbs | Also, didn't fesco kick something else down to us? I recall seeing a message about it but I wasn't able to find it. | 12:23 |
| abadger1999 | spot: Have a new version of that? Fro mthe discussion I think I'm +1 on it. | 12:25 |
| abadger1999 | tibbs: Yeah... trying to find that too. | 12:25 |
| spot | abadger1999: no, its the same version, just without the %clean changes | 12:25 |
| abadger1999 | tibbs: https://fedoraproject.org/wiki/Features/OSGiAutoDeps | 12:25 |
| spot | because Panu wants to fix it upstream as I'd suggested | 12:26 |
| tibbs | abadger1999: Not really sure why that would be a "feature", anyway. | 12:26 |
| abadger1999 | tibbs: Right. That's why FESCo kicked it to us :-) | 12:26 |
| tibbs | We did the same thing as part of the Ocaml guidelines, but this isn't accompanied by guidelines. | 12:26 |
| abadger1999 | Unfortunately, there doesn't seem to be any guidelines changes yet. | 12:27 |
| abadger1999 | Yeah. | 12:27 |
| spot | yeah, so they need to draft how the guidelines changes would be. | 12:27 |
| * abadger1999 is slow on the keyboard today | 12:27 | |
| tibbs | Are there any guidelines at all for OSGi stuff currently? Does it just fall under the eclipse plugin stuff or is it something different? | 12:28 |
| tibbs | I don't really know what OSGi is or does. | 12:28 |
| spot | tibbs: me neither | 12:28 |
| tibbs | I mean, conceptually we want to do as much of this as makes sense. | 12:28 |
| spot | yeah, i'm not against the idea at all, just want to see how it will be implemented && how it affects the guidelines | 12:29 |
| tibbs | The feature page strongly implies that "OSGi package" === "eclipse plugin package". | 12:29 |
| tibbs | In which case we're just talking about dropping manual deps from any eclipse plugin package. | 12:29 |
| abadger1999 | <nod> | 12:30 |
| tibbs | See the bottom of https://fedoraproject.org/wiki/Packaging/EclipsePlugins | 12:31 |
| tibbs | Otherwise those guidelines don't really mention dependencies. | 12:33 |
| abadger1999 | Okay, so for OSGI -- respond to Feature submitter to with 1) please submit the modified Packaging Guideline for Eclipse Plugins. 2) Clarify whether Eclipse plugins are the only thing that useOSGI Dependencies. | 12:33 |
| rdieter | and perhaps a spec template | 12:33 |
| rdieter | part of 1) I guess | 12:34 |
| tibbs | I don't think the spec template would change, honestly. | 12:34 |
| tibbs | Maybe the "eclipse-platform" dependency would be automatic, I'm not sure. | 12:34 |
| rdieter | ok, things would "just work"? if so, nice | 12:34 |
| spot | abadger1999: sounds right. | 12:34 |
| tibbs | abadger1999: +1. | 12:34 |
| spot | So, lets talk about the other agenda item: https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29 | 12:35 |
| tibbs | Not much to that draft. | 12:35 |
| spot | yep. pretty much common sense. The only concern i had was if people took a F10+ spec and backed it to EPEL, it might do system damage | 12:36 |
| tibbs | Right, but that was only conjecture. | 12:36 |
| spot | but i tested on EL4 and EL5 and neither had any problem there. | 12:36 |
| spot | So, I | 12:36 |
| spot | I'm +1 | 12:36 |
| abadger1999 | +1 | 12:37 |
| rdieter | +1 | 12:37 |
| SmootherFrOgZ | +1 | 12:37 |
| tibbs | I'm all for removing crap. +1. | 12:37 |
| spot | okay, thats +5 | 12:37 |
| tibbs | But didn't you want to do this in conjunction with some other changes? | 12:37 |
| spot | yeah, but the other changes don't need FPC signoff | 12:37 |
| tibbs | True. | 12:38 |
| spot | i will just do them at the same time | 12:38 |
| tibbs | But don't we need to change a bunch of templates and such? | 12:38 |
| spot | i have acl access to that package (and i think i may be the last one to own) | 12:38 |
| spot | tibbs: well, i'll go through and do cleanups | 12:38 |
| tibbs | We should definitely announce all of the changes clearly, because I think this may be confusing to many folks. | 12:39 |
| * spot nods | 12:39 | |
| spot | so, i think thats it... unless anyone has something else. :) | 12:39 |
| tibbs | Chris Weyl's thing. | 12:39 |
| tibbs | https://fedoraproject.org/wiki/Features/BetterRpmAutoReqProvFiltering | 12:39 |
| tibbs | This is another thing that really isn't a feature. | 12:40 |
| tibbs | As a meta-topic, I'm curious as to why folks are sending this kind of thing to fesco instead of us. | 12:40 |
| spot | he basically wants to add those macros to redhat-rpm-config, right? | 12:40 |
| tibbs | Yes, plus they would get packaging guidelines on their use. | 12:40 |
| tibbs | I agree that we really need something like this but I haven't looked at the implementation. | 12:41 |
| spot | so, lets see the packaging guidelines on their use first | 12:41 |
| spot | i'm not opposed to this standardization | 12:41 |
| tibbs | You can basically get that from the "detailed description" section, but it's all formatted as a feature proposal, not a guidelines proposal. | 12:42 |
| tibbs | I'll reply on-list to ask that this be formatted as a guidelines proposal if he wants to do it that way. | 12:45 |
| tibbs | I think fesco would just kick it over to us anyway. | 12:45 |
| tibbs | But it would be good if someone who understands this stuff could evaluate the actual macros in use. | 12:46 |
| tibbs | The interface looks nice, at least. | 12:46 |
| tibbs | Note also that there's a behavioral change for everything perl-related buried/hidden down in the macros, which also needs to be discussed, I think. | 12:47 |
| abadger1999 | What's the change? | 12:50 |
| tibbs | It filters the auto-deps for .so files in the perl-specific directories. | 12:52 |
| tibbs | It's a good change, but it does mean that there are two different things wrapped up in the single feature document. | 12:53 |
| tibbs | One is the infrastructure for filtering deps, which is good. | 12:53 |
| tibbs | The other is the filter of perl internal .so files. | 12:53 |
| tibbs | I think they should be discussed separately. | 12:53 |
| abadger1999 | <nod> | 12:56 |
| spot | okay, so we need Chris to draft them up as separate items | 13:04 |
| spot | anything else? | 13:04 |
| spot | okay. i'll take silence as a no and close out this meeting. thanks everyone. | 13:05 |