From Fedora Project Wiki

Fedora Packaging Committee Meeting 2009-04-28


  • Denis Leroy (delero)
  • Jason Tibbitts (tibbs)
  • Rex Dieter (rdieter)
  • Tom Callaway (spot)
  • Toshio Kuratomi (abadger1999)


  • Dominik Mierzejewski (Rathann|work)
  • Hans de Goede (hansg)
  • Ralf Corsepius (racor)
  • Xavier Lamien (SmootherFrOgZ)


There were no completed votes this week.

Other Discussions

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

IRC Logs

* spot looks around for FPC folks 12:01
spot abadger1999, tibbs, rdieter, delero, SmootherFrOgZ: ping 12:03
tibbs HHowdy. 12:03
abadger1999 pong. I'm here. 12:03
* delero is here 12:03
rdieter yo 12:03
spot i don't think racor is coming due to time conflicts, but he did send his votes for todays items via email 12:05
spot we have quorum though, so lets go ahead and get started 12:06
spot first item: GConf scriptlets: 12:07
abadger1999 So spstarr wrote the first section of this by looking at what SuSE does. 12:08
abadger1999 (just pinged him in #fedora-devel to see if he's available). 12:08
delero do we know how significant the speedup is ? 12:08
tibbs This is way complicated, though. I'd really want buyin from our Gnome maintainers. 12:08
abadger1999 spstarr had generated some numbers but I don't recall what they were. It was significant. 12:09
tibbs Actually it's kind of ludicrously complicated. 12:09
spot tibbs: agreed. i'd want buyoff from them before we even consider adding a pile of painful macros 12:09
abadger1999 I agree, so I wrote a much simplified alternative in the bottom section. 12:09
abadger1999 mclasen liked my alternative. 12:09
abadger1999 (I think that he liked anything that hid things behind macros) 12:10
rdieter mclassen helped spstarr with a revision or 2 of what has been proposed. I assume he's for it 12:10
tibbs Is mclasen the only person we want to see approval from? 12:10
abadger1999 Dunno. He's the one from the desktop team that comments on FPC proposals the most. 12:11
rdieter during/after meeting we (I) could drop a message to fedora-desktop list asking for further feedback 12:12
--> mclasen has joined this channel (n=mclasen@nat/redhat/x-f2ba5db99bc02eb5). 12:12
abadger1999 Since spstarr isn't here at the moment, can we defer this to the end and talk about it then? 12:12
spot well, since mclasen is here, i'd like his thoughts on the draft 12:12
abadger1999 Ah cool :-) 12:12
spot I have a few points: I think simplifying the scriptlets is a good thing, but i don't want to use macros to obfuscate other things 12:13
spot e.g. I do not like %{magic_requires_for_things}, i much prefer: Requires(pre): %{requires_for_scriptlets} 12:14
mclasen I think opencoding these scriptlets in hundreds of spec files is error-prone and repetitive 12:14
mclasen but I agree that the requires part is not necessary 12:14
spot mclasen: how do you feel about the revised macro proposal at the bottom of: 12:15
tibbs I do wish we could keep these drafts a bit cleaner. I can't really understand from this draft what is being proposed by whom. 12:16
* abadger1999 be sure and login -- looks like the wiki's caching is interfering 12:17
tibbs The stuff after "Discussion" is a counterproposal, but it doesn't seem complete. 12:17
spot yeah, it is a bit of a mess. 12:17
abadger1999 yeah... so everything above Discussion is spstarr's work. Everything below Discussion is my work. 12:17
abadger1999 I mainly focused on whether we could get some macros that were less complex. 12:18
spot yeah, i think keeping the macros simple and to a minimum is key 12:18
tibbs So the spec template is the same in either case? 12:19
abadger1999 Before we write it up, it would need to have a ScriptletSnippets entry that explained it... the outline of that is in the comments of the rpm macro script. 12:19
tibbs Well, no. 12:19
abadger1999 That's changed too. 12:19
spot no, the spec template would be different, look at the comments in the second scriptlet header 12:19
abadger1999 if you read the comments of each rpm macro script you'll see. 12:19
abadger1999 Another thing I didn't like about the SuSE method is that the macros are different in different cases. 12:20
abadger1999 Sometimes you can use find_gconf_schemas as documented in the proposed update... but other times you need to use def_gconf_schemas and add_gconf_schemas instead. 12:20
spot abadger1999: have you tested your macros? 12:21
abadger1999 spot: Yes, and they don't quite work yet. 12:21
abadger1999 rdieter: Have you messed with rpm macro files? 12:21
spot okay, i'd like to do this then... 12:21
spot can we table this until next meeting, so that A) the macros can be tested 12:22
rdieter abadger1999: i've dabbled here and there. :) 12:22
spot B) the draft can be cleaned up in a separate proposal 12:22
rdieter abadger1999: mind sending me what you have? 12:22
tibbs Can we agree that we'd like to see something simpler than the SuSE macros? 12:22
spot yeah, i like the direction that abadger1999 is taking it much better than the SuSE style 12:22
abadger1999 rdieter: Yep, I'll tar up a small spec and the macro file. 12:23
abadger1999 spot: Cool. Sounds like a good plan. 12:23
spot okay, lets move on to the next item: 12:24
delero another heavyweight 12:24
rdieter step 1: flog globus upstream for inducing such packaging pain (reminds me of sage) (I'm only slighly kidding) 12:25
delero is the globus packaging going to be the work of a single packager ? 12:25
abadger1999 So far it has been. 12:26
mattiasellert I'm here by the way... 12:26
abadger1999 These instructions seem to be comprehensive enough that someone else could work on it too, though. 12:26
tibbs Ralf's opinion was that this doesn't need specialized guidelines. 12:26
abadger1999 mattiasellert: Excellent. 12:26
spot i'm not really sure why there is so much hopping around handling the LICENSE file as a %doc 12:26
rdieter that's so Ralf 12:26
abadger1999 mattiasellert is the author of the proposal. 12:26
tibbs I don't necessarily agree but the comment does have merit. 12:26
rdieter tibbs: nod, it's more a howto than anything else 12:27
delero a lot of work went into this draft... 12:27
spot the spec examples have a creation of the %docdir, then copying the license into %docdir, then multiple lines in %files to cover the docdir as a %dir and the license as a file 12:27
spot when the same end result occurs for %doc LICENSE_FILE 12:27
mattiasellert No that would delete the rest of the documentation. 12:28
spot i don't think so... 12:28
spot especially since in your spec example, you're making the $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version} directory just before you copy the license into it (and after running make install) 12:29
abadger1999 Some packages have documentation and some do not. 12:29
mattiasellert exactly 12:30
abadger1999 and since it's a mkdir -p it won't fail if the dir already exists. 12:30
spot even if they do, listing %doc LICENSE in %files should be additive rather than removing the directory to replace it with the license file 12:30
delero right 12:30
spot thats how it works for the other... umm... all Fedora packages. :) 12:30
* abadger1999 recalls a discussion of that in fedora-devel where %doc removed the stuff installed in /usr/share/doc/PACKAGE-VERSION. 12:30
mattiasellert It does. 12:31
spot okay, well, i won't harp on that point, but we should get that fixed. 12:31
abadger1999 This isn't the one I recall but: 12:31
spot i tend to disagree with ralf, we have always permitted good type specific packaging guidelines 12:32
spot the only thing that i see missing is any discussion of formal namespacing 12:33
spot e.g. globus-$foo 12:33
spot mattiasellert: will all globus toolkit packages start with globus- ? or just the libraries? 12:34
tibbs I agree; I don't see how this is measurably different from, say, Ruby Gems or Perl modules in deserving their own guidelines. 12:34
tibbs The fact that things have to be so incredibly complicated only reinforces that. 12:34
spot indeed. also, having guidelines with good spec templates helps reviewers 12:35
mattiasellert The vast majority are called globus-, there are a few that have other namespaces, e.g. gaa- and gridshib-. Then there are a few oddballs. 12:36
tibbs I really wish we could do without some of the terrible !?fedora and !?rhel conditionals. 12:36
spot mattiasellert: okay, so it sounds like you don't need a global namespace like we do with perl or ruby, for example 12:36
tibbs When you see things like %if %{?fedora}%{!?fedora:0} >= 3 you have to wonder. 12:36
spot mattiasellert: any chance you can narrow those sorts of things to Fedora 6? 12:37
spot 6+, rather 12:37
tibbs Why not 9+? 12:37
spot well, we've permitted things for two revs off the last active release for items like Provides 12:38
spot which would be 7, rather than 9. 12:38
tibbs But this is all going to be new packages. 12:38
spot yeah, good point. 12:38
spot removing that (the rhel stuff can stay for epel) will simplify the spec quite a bit 12:38
spot mattiasellert: what do you think about that? 12:39
abadger1999 Shold be able to use %if 0%{?fedora} >= 9, yes? 12:39
spot abadger1999: yep. 12:39
spot aside from that macro issue, i'm inclined to +1 here. its obvious a lot of effort went into this draft. 12:40
abadger1999 things that aren't in/differ from the Guidelines: 12:41
abadger1999 "Obtaining source" -- upstream provides a tarball but it's huge and silly about what it provides 12:41
abadger1999 doc packages: separate subpackage regardless of size 12:41
abadger1999 the setup packages explanation 12:41
abadger1999 information about using gpt and what gpt files are. 12:42
abadger1999 So definitely some new stuff. 12:42
spot since the docs come in their own gpt file listing, i'm inclined to permit the subpackages by default, regardless of size 12:42
spot we generally permit the maintainers discretion on such matters 12:42
spot if it is absurd, it will get pointed out during review 12:43
rdieter good stuff by the looks of it, +1 here too 12:43
abadger1999 I think this is a good thing to have: +1 12:44
spot +1, with the old fedora macros removed 12:44
tibbs I'm looking to see if there's anything else that could be simplified. 12:46
spot okay. 12:46
tibbs The %install section in the first template is really scary. Is all of that actually needed for a typical library package? 12:46
delero +1 12:47
<-- mclasen has left this channel ("There must be some way out of here."). 12:47
spot tibbs: it seems to be, but it is also well commented 12:48
tibbs I mean, a simple pushd at the top could shorten a lot of those macros. 12:48
abadger1999 mattiasellert: Perhaps this one is specific to a specific package? # Remove unwanted documentation 12:50
* spot wonders if mattiasellert is still with us. :) 12:52
mattiasellert Not really - some versions of doxygen create a bunch of crap. 12:52
tibbs We should document which versions. 12:52
tibbs Otherwise we get cargo cult specfiles. 12:52
tibbs "The template said that I need this. I have no idea if it really does anything." 12:53
mattiasellert OK, I'll compile a list. 12:54
spot so, it seems like there are three things: A) the spec tool (and templates) needs to limit disttag macro use to rhel and fedora >= 9 12:55
spot B) the spec tool should use pushd/popd to simplify the %install section 12:55
spot (and templates) 12:55
spot C) documenting the versions of doxygen that need to be cleaned up after 12:55
spot anything i missed? 12:56
tibbs "B" only if it makes sense. It might not. Another possibility would be to stuff $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name} in a macro. 12:56
spot tibbs: that would be another way to simplify it 12:57
spot mattiasellert: are you willing to make those changes? 12:57
mattiasellert Yes, I will look into adopting these suggestions. 12:58
spot okay, then lets table this for next meeting, pending those changes. 12:58
spot if they end up being done sooner, we can almost certainly do a vote over email 12:58
spot the next item: 12:59
tibbs Is there an "is 64-bit" macro predefined by RPM? 12:59
spot tibbs: there was talk of making one, but i don't think it happened 12:59
rdieter my usual test for 64bitness is %if "%{_lib}" == "lib64" 12:59
spot rdieter: that isn't true on ia64 12:59
tibbs Because the leading %ifarch is bound to give us problems. 12:59
rdieter lovely. 13:00
tibbs __isa_bits 13:00
spot ahh, you could use __isa_bits 13:00
spot but only on fedora, not epel 13:00
rdieter woo 13:00
spot as to the Compiler Flags draft... i think i agree with Ralf. (shocking, i know) 13:02
tibbs Yeah, the guidelines don't need to be a howto document. 13:02
tibbs What prompted this draft? 13:02
spot i think the 0 size debuginfo packages did 13:02
spot the advice in the draft isn't wrong, but it isn't right for all packages, and i'd be concerned that reviewers might start expecting to see CFLAGS= in packages where it isn't needed 13:04
abadger1999 yeah. the chain was 0 size debuginfo; How do I get %{optflags} into my build? Here's how. Why isn't that in the Guidelines? 13:04
tibbs Because that's not what Guidelines are for? 13:04
spot a separate document on "how to ensure you are using optflags in your build" would be valuable 13:05
abadger1999 Despite: "Most C, C++, and Fortran programs will pick up the correct compiler flags if you use a macro that automatically sets them to build the package, such as %configure or %cmake" ? 13:05
spot but i'm not convinced it belongs in the guideline 13:05
tibbs The guidelines say that the compiler flags must be correct. It doesn't tell you how to read makefiles and edit them if necessary 13:05
tibbs abadger1999: So I guess that's a proposal for stripping that sentence from the guidelines, which I would agree with. 13:06
rdieter can the guidelines link-to or refer to this proposal (or something like it) for further details? 13:06
tibbs The problem is that we're sort of schizophrenic on the issue, because we include specfile templates and such. 13:06
spot rdieter: absolutely 13:06
spot i would much rather let this live in Packagers/ 13:07
spot and link to it from the Guidelines 13:07
rdieter better 13:07
spot so, i will formally -1 on those grounds 13:07
tibbs Agreed. 13:08
spot okay, thats all the items on today's agenda 13:08
spot any other items? 13:08
spot i am 7 minutes late for the board meeting 13:08
abadger1999 Not that I can think of. 13:09
tibbs Meeting time again. Hans has complained on-list that the time won't work for him, but he hasn't provided a list of times that work for him. 13:09
spot so i am closing this out. 13:09
tibbs The same for Ralf. I'm not sure what to do. 13:09
spot ah yes, everyone be sure to send in your times 13:09
abadger1999 rdieter, delero: Can you guys be sure to send in the times that work for you? 13:09
delero will do 13:09
rdieter abadger1999: consider me 100% flexible, I can make pretty much any time 13:09
spot tibbs: i'll talk to Hans, as to Ralf.... well. i'm not sure how we can get it from him. 13:09
spot rdieter: except for the KDE SIG meeting time! 13:10
rdieter we can move, that too, if needed 13:10
spot fair enough. 13:10
spot okay, meeting done! 13:12
spot thanks everyone 13:12
abadger1999 thanks for running it 13:12