From Fedora Project Wiki

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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"