From Fedora Project Wiki
Fedora Packaging Committee Meeting of {2007-07-03}
Present
- AxelThimm (
thimm) - DavidLutterkort (
lutter) - JasonTibbitts (
tibbs) - JesseKeating (
f13) - RalfCorsepius (
racor) - RexDieter (
rdieter) - TomCallaway (
spot) - ToshioKuratomi (
abadger1999) - VilleSkyttä (
scop)
Writeups
The following draft has been accepted by FESCO and is to be written into the guidelines:
Votes
The following proposals were considered:
- Stop recommending the use of %{?_smp_mflags}
- See thread beginning at https://www.redhat.com/archives/fedora-packaging/2007-July/msg00000.html
- Rejected (1 - 5)
- Voting for: thimm (on-list)
- Voting against: tibbs spot f15 abadger1999 scop
Other Discussions
The following additional items were discussed; see the logs for full details.
- Relaxing restrictions on compat- package naming.
- https://www.redhat.com/archives/fedora-packaging/2007-June/msg00182.html
IRC Logs
[12:00] * spot is here
[12:00] * tibbs here
[12:01] --> scop has joined this channel (n=scop@cs181043142.pp.htv.fi).
[12:03] <spot> scop, abadger1999, lutter, f13?
[12:04] <abadger1999> here
[12:04] <tibbs> f13 indicated he'd be late.
[12:04] <spot> ok.
[12:05] <tibbs> [10:58] <f13> spot: I'll be a bit late to packaging meeting, going to soccer, leaving around 1, so maybe 30 minutes late.
[12:05] * spot has been offline all morning, moving my e10k into a different part of the chicago office
[12:06] <spot> well, we're quite short of quorum at the moment
[12:06] <scop> pong
[12:06] <spot> thats 4.
[12:07] <spot> lutter would make 5, but i'm not sure he's awake. :)
[12:07] <abadger1999> heh -- it's 10AM on this coast.
[12:07] <abadger1999> Probably just commuting.
[12:08] <spot> well, if push comes to shove, we can wait 20 min for f13
[12:08] <spot> theres a fair amt of "easy items" on the todo list
[12:08] <jeremy> lutter is on vacation this week, iirc
[12:08] <tibbs> The commit id thing was ratified, so I'll write it up and announce it.
[12:10] <tibbs> Hmm.
[12:10] <abadger1999> I'd like to get feedback/vote on this: https://www.redhat.com/archives/fedora-packaging/2007-June/msg00182.html
[12:10] <abadger1999> Do you guys like it? If so we can vote and I can go to the list to see if I can get the rest.
[12:11] <abadger1999> (rest of the votes needed to pass)
[12:11] <tibbs> I think that the spirit of the existing rule is good; the newer version should be the one without the explicit version.
[12:12] <spot> rdieter is at akademy
[12:12] <scop> I agree with tibbs
[12:12] <tibbs> However, there are reasonable cases where this isn't the best thing.
[12:12] <spot> i'm ok with the rewording
[12:12] <spot> the spirit was to prevent confusion
[12:12] <tibbs> I'd be OK with relaxing it to a recommendation but not saying "do what you want".
[12:12] <abadger1999> This is specifically blocking: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246046
[12:12] <scop> I'd rather have old versions renamed to compat-*
[12:13] <abadger1999> scop: Do we want to separate the case where we only provide the dynamic library vs the case where we provide the whole stack (libraries + headers)
[12:14] <abadger1999> So compat-* is for the library only and [basename] [version] is for the whole stack?
[12:14] <scop> personally, I'd be in favour of using compat-* for both cases
[12:14] <abadger1999> k
[12:14] <spot> yeah. i'm a big fan of the namespace. :)
[12:14] <scop> both as in compat-gtk+-devel (whole old stack)
[12:15] <tibbs> The thing about gtk+ and gtk2 is that gtk2 is the actual name of the software, isn't it?
[12:15] <scop> ditto compat-foo if some package goes compat and drops devel files while at it
[12:15] <abadger1999> tibbs: yes and no:
[12:15] <scop> no, it's "GTK+"
[12:16] <abadger1999> The tarball is just gtk+
[12:16] <spot> yeah, gtk2 is legacy badness.
[12:17] <abadger1999> But the files all install to gtk-2.0 directories.
[12:17] <abadger1999> directories/filenames.
[12:18] * spot notes that gtk-2.0 is diff from gtk2
[12:18] <abadger1999> So upstream was taking the gtk1 vs gtk2 split into consideration
[12:18] <scop> I don't think we should pay attention to install dir names when deciding what's the "correct" name for a package
[12:18] <scop> there are already enough moving parts IMO...
[12:19] <spot> indeed.
[12:19] <abadger1999> No problems. KISS is good.
[12:20] <abadger1999> What would be the factors to consider?
[12:21] <spot> well, i think it would be first important to identify which package is the "compat" package
[12:22] <scop> there can be several compat ones, no?
[12:22] <spot> sure.
[12:22] <abadger1999> BTW, do you want me to see if mclasen is available to tell us why he wants the newer one to be versioned?
[12:22] <spot> should we say that anything < current needs to be compat?
[12:22] <spot> abadger1999: sure.
[12:22] <scop> spot, I suppose so
[12:23] <scop> gtkhtml, compat-gtkhtml3{1,2,3,4,5,6,7,8,9}
[12:25] <scop> btw, keeping the latest with the basename and renaming older ones to compat-* screws CVS history pretty efficiently
[12:25] <scop> (if we want base name == CVS dir name)
[12:25] <spot> hmm, thats a point.
[12:26] <spot> but we're considering compat-* packages as new packages anyways
[12:26] <spot> (need to be reviewed)
[12:26] <abadger1999> Hey mclasen. So currently we're discussing this: https://www.redhat.com/archives/fedora-packaging/2007-June/msg00182.html
[12:26] <scop> sure
[12:27] <mclasen> I think all of foo-compat+foo, foo1+foo, and foo+foo2 have their valid uses
[12:27] <mclasen> and i'd hate the guildelines to be overly narrow there
[12:29] <spot> well, i think that the compat-* namespace makes things clear as to what is current and what is not
[12:29] <abadger1999> spot: If upstream is releasing onto two branches, wouldn't both be current?
[12:30] <spot> i suppose so.
[12:30] <scop> well, depends
[12:31] <scop> but if there are separate active upstreams for foo1 and foo2, then I think it'd be more likely that neither is necessarily a compat
[12:31] <spot> yeah, but in that case, would we permit a mixed naming? a foo1+foo or foo2+foo1 ?
[12:31] <scop> yes
[12:32] <scop> an old branch can be in strict security-fix maintenance mode, I don't think that qualifies as non-compat
[12:32] <scop> eg. libpng10 IIRC
[12:32] <spot> do we want to have strict judgement calls on all of this?
[12:32] <spot> or more of a KISS approach, let the maintainers use their best judgement
[12:32] <mclasen> from my perspective, compat- should be limited to support for third-party apps, ie nothing in our repository uses the old library anymore
[12:33] <spot> mclasen: we've used compat- before for when the majority of apps have moved to the newer lib, but some have not yet (ever) moved
[12:34] <mclasen> some of the intended restrictions on -compat (ie stripping of headers, etc) are not really compatible with continued building of new stuff against them
[12:35] <spot> intended restrictions?
[12:35] <mclasen> at least that was my understanding
[12:35] <mclasen> when I initially proposed compat-gtksourceview as a name
[12:35] <skvidal> mspevack: ping
[12:35] <spot> afaik, we have no guidelines on compat packages
[12:35] <mclasen> people told me there would be extra restrictions like that
[12:36] <mclasen> maybe that was just reviewers making stuff up
[12:36] <spot> the only item i ever wrote was here:
[12:36] <spot> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-48ca801d3f8b9f46713343760949349fba78e644
[12:36] <spot> and it doesn't mention the compat namespace at all
[12:36] <abadger1999> mclasen: That's a miscommunication.
[12:37] <abadger1999> mclasen: I wrote: "With C libraries, header files and other development bits may be pruned out."
[12:37] <abadger1999> because many of the compat-* packages are compatibility with third party only.
[12:38] <spot> i think it would be up to the maintainer as to what files are relevant to include in a compat package
[12:39] <abadger1999> It was an example of why a compat-* package should have a new review.
[12:39] <spot> abadger1999: ah ok.
[12:39] <spot> well, FESCO says that compat-* packages must have new review
[12:39] <spot> so that issue is set in stone. :)
[12:41] <scop> using compat-* for all old packages, including ones that ship bits used as BR's (-devel or not) would actually result in annoying BR shuffling between branches
[12:41] <spot> scop: sure.
[12:41] <scop> so I withdraw that opinion expressed earlier :)
[12:41] <spot> i think i'm ok with the loosening of the policy on naming as abadger1999 suggests
[12:41] <scop> I'm starting to lean towards that too
[12:42] <spot> but... we don't have quorum
[12:42] <spot> so, abadger1999, take this to the list and try to get your votes? :)
[12:42] <abadger1999> Yep. I'll send out an announcement that it was discussed and "Please vote now"
[12:43] <scop> good
[12:43] <scop> I did some research about %pretrans for UsersAndGroups
[12:43] <scop> short version: no go
[12:43] <spot> scop: ok, good to know.
[12:43] <scop> failing %pretrans doesn't abort *anything*, not even installation of the package whose %pretrans failed
[12:43] <spot> scop: nice.
[12:44] <f13> I'm here now.
[12:44] <tibbs> Someone added water to the instant quorum.
[12:44] <spot> scop: we'll look at that draft next week
[12:44] <spot> now that we have quorum
[12:44] <spot> lets go ahead and do thimm's item
[12:45] <scop> spot, yep, I'll make the "let' %pre fail" changes before that
[12:45] <spot> "I'd like to propose to reverse the recommendation to use smp_flags with the opposite (make the opt-out an opt-in)."
[12:45] <spot> he means smp_mflags
[12:45] <tibbs> -1
[12:45] <spot> -1
[12:45] <f13> -1
[12:45] <abadger1999> -1
[12:46] <scop> -1
[12:46] <spot> ok, thats pretty soundly defeated.
[12:46] <abadger1999> We should make it more prominent that smp_mflags is one of the first things to remove when something is screwy.
[12:46] <f13> I'm all for adding warnings around it or leaving breadcumbs for people to help diagnose build issues, but smp_flags should be on by default, removed if you know it will break things with comments.
[12:47] <spot> abadger1999: agreed, i'm not opposed to adding text to the smp_mflags item saying that
[12:47] <f13> and if dwmw2 were here, he'd probably want an smp_flags blocker bug.
[12:47] <scop> would trimming -j* from MAKEFLAGS in the environment in cases where we know it has problems be overkill in addition to leaving out %{?_smp_mflags}?
[12:48] <spot> scop: probably.
[12:48] <spot> but i don't want to say that a motivated maintainer can't do it.
[12:48] <scop> (probably yes, just thought I'd mention it, although I'm not even sure if it can get to the build env from the user's)
[12:48] <tibbs> I build on an 8-way and occasionally find some weirdness, but I always turn it off when I see a build failure just to get sequential build output.
[12:48] <f13> yeppers.
[12:49] <spot> any other quick items for today?
[12:50] <tibbs> Didn't notting have a proposal?
[12:50] <tibbs> Something about moving ldconfig to posttrans?
[12:50] <scop> I think it had some flaws and is being refined
[12:50] <tibbs> I hope it works out.
[12:50] <scop> %posttrans isn't run on erase-only transactions
[12:51] <spot> tibbs: not on the schedule or on fedora-packaging
[12:51] <f13> I suppose talking about perl is out?
[12:51] <spot> what about perl?
[12:52] <abadger1999> f13: I saw that in the releng notes... is it really our ball of wax?
[12:52] <f13> or instead of talking about perl, do we as the guidlines maintainers feel that we dictate what is or isn't in the default buildroot?
[12:52] <spot> the minimum buildroot is FESCo
[12:52] <f13> ok, punt to FESCo
[12:52] <f13> wheee
[12:52] <f13> fwiw, I think the moon is blue because Ralf and I agree on this one
[12:52] * scop giggles
[12:53] <spot> any other items?
[12:53] <f13> I can't think of anything.
[12:53] <f13> but then again, I can't brain today, I have the dumb.
[12:54] <skvidal> f13: you own the dumb :)
[12:54] * warren watches the perl issue getting punted to yet another authority
[12:54] <f13> *pout*
[12:54] <skvidal> f13: :)
[12:54] <spot> ok, we're done. i'm going to go put my e10k back together then look for food.
[12:54] <spot> thanks all.