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:

Other Discussions

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

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.
Retrieved from "https://fedoraproject.org/w/index.php?title=Packaging:Minutes20070703&oldid=66555"