Packaging:Minutes20070703

Present

 * AxelThimm
 * DavidLutterkort
 * JasonTibbitts
 * JesseKeating
 * RalfCorsepius
 * RexDieter
 * TomCallaway
 * ToshioKuratomi
 * VilleSkyttä

Writeups
The following draft has been accepted by FESCO and is to be written into the guidelines:


 * http://fedoraproject.org/wiki/PackagingDrafts/CommitIDs

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] scop, abadger1999, lutter, f13? [12:04] here [12:04] f13 indicated he'd be late. [12:04] ok. [12:05] [10:58]  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] well, we're quite short of quorum at the moment [12:06] pong [12:06] thats 4. [12:07] lutter would make 5, but i'm not sure he's awake. :) [12:07] heh -- it's 10AM on this coast. [12:07]  Probably just commuting. [12:08]  well, if push comes to shove, we can wait 20 min for f13 [12:08]  theres a fair amt of "easy items" on the todo list [12:08]  lutter is on vacation this week, iirc [12:08]  The commit id thing was ratified, so I'll write it up and announce it. [12:10]  Hmm. [12:10]  I'd like to get feedback/vote on this: https://www.redhat.com/archives/fedora-packaging/2007-June/msg00182.html [12:10]  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]  (rest of the votes needed to pass) [12:11]  I think that the spirit of the existing rule is good; the newer version should be the one without the explicit version. [12:12]  rdieter is at akademy [12:12]  I agree with tibbs [12:12]  However, there are reasonable cases where this isn't the best thing. [12:12]  i'm ok with the rewording [12:12] the spirit was to prevent confusion [12:12] I'd be OK with relaxing it to a recommendation but not saying "do what you want". [12:12] This is specifically blocking: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246046 [12:12] I'd rather have old versions renamed to compat-* [12:13] 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] So compat-* is for the library only and [basename] [version]  is for the whole stack? [12:14] personally, I'd be in favour of using compat-* for both cases [12:14] k [12:14]  yeah. i'm a big fan of the namespace. :) [12:14] both as in compat-gtk+-devel (whole old stack) [12:15]  The thing about gtk+ and gtk2 is that gtk2 is the actual name of the software, isn't it? [12:15]  ditto compat-foo if some package goes compat and drops devel files while at it [12:15]  tibbs: yes and no: [12:15]  no, it's "GTK+" [12:16]  The tarball is just gtk+ [12:16]  yeah, gtk2 is legacy badness. [12:17]  But the files all install to gtk-2.0 directories. [12:17]  directories/filenames. [12:18]  * spot notes that gtk-2.0 is diff from gtk2 [12:18]  So upstream was taking the gtk1 vs gtk2 split into consideration [12:18]  I don't think we should pay attention to install dir names when deciding what's the "correct" name for a package [12:18]  there are already enough moving parts IMO... [12:19]  indeed. [12:19]  No problems.  KISS is good. [12:20]  What would be the factors to consider? [12:21]  well, i think it would be first important to identify which package is the "compat" package [12:22] there can be several compat ones, no? [12:22]  sure. [12:22] 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] should we say that anything < current needs to be compat? [12:22] abadger1999: sure. [12:22] spot, I suppose so [12:23]  gtkhtml, compat-gtkhtml3{1,2,3,4,5,6,7,8,9} [12:25] btw, keeping the latest with the basename and renaming older ones to compat-* screws CVS history pretty efficiently [12:25] (if we want base name == CVS dir name) [12:25] hmm, thats a point. [12:26] but we're considering compat-* packages as new packages anyways [12:26] (need to be reviewed) [12:26] Hey mclasen. So currently we're discussing this: https://www.redhat.com/archives/fedora-packaging/2007-June/msg00182.html [12:26] sure [12:27] I think all of foo-compat+foo, foo1+foo, and foo+foo2 have their valid uses [12:27] and i'd hate the guildelines to be overly narrow there [12:29] well, i think that the compat-* namespace makes things clear as to what is current and what is not [12:29] spot: If upstream is releasing onto two branches, wouldn't both be current? [12:30] i suppose so. [12:30] well, depends [12:31] 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] yeah, but in that case, would we permit a mixed naming? a foo1+foo or foo2+foo1 ? [12:31] yes [12:32] an old branch can be in strict security-fix maintenance mode, I don't think that qualifies as non-compat [12:32] eg. libpng10 IIRC [12:32] do we want to have strict judgement calls on all of this? [12:32] or more of a KISS approach, let the maintainers use their best judgement [12:32] 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] 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] 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] intended restrictions? [12:35] at least that was my understanding [12:35] when I initially proposed compat-gtksourceview as a name [12:35] mspevack: ping [12:35] afaik, we have no guidelines on compat packages [12:35] people told me there would be extra restrictions like that [12:36] maybe that was just reviewers making stuff up [12:36]  the only item i ever wrote was here: [12:36] http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-48ca801d3f8b9f46713343760949349fba78e644 [12:36] and it doesn't mention the compat namespace at all [12:36] mclasen: That's a miscommunication. [12:37] mclasen: I wrote: "With C libraries, header files and other development bits may be pruned out." [12:37] because many of the compat-* packages are compatibility with third party only. [12:38] i think it would be up to the maintainer as to what files are relevant to include in a compat package [12:39] It was an example of why a compat-* package should have a new review. [12:39] abadger1999: ah ok. [12:39] well, FESCO says that compat-* packages must have new review [12:39] so that issue is set in stone. :) [12:41] 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]  scop: sure. [12:41]  so I withdraw that opinion expressed earlier :) [12:41] i think i'm ok with the loosening of the policy on naming as abadger1999 suggests [12:41] I'm starting to lean towards that too [12:42] but... we don't have quorum [12:42] so, abadger1999, take this to the list and try to get your votes? :) [12:42] Yep.  I'll send out an announcement that it was discussed and "Please vote now" [12:43]  good [12:43]  I did some research about %pretrans for UsersAndGroups [12:43]  short version: no go [12:43]  scop: ok, good to know. [12:43]  failing %pretrans doesn't abort *anything*, not even installation of the package whose %pretrans failed [12:43]  scop: nice. [12:44]  I'm here now. [12:44]  Someone added water to the instant quorum. [12:44]  scop: we'll look at that draft next week [12:44]  now that we have quorum [12:44]  lets go ahead and do thimm's item [12:45]  spot, yep, I'll make the "let' %pre fail" changes before that [12:45]  "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]  he means smp_mflags [12:45]  -1 [12:45]  -1 [12:45]  -1 [12:45]  -1 [12:46]  -1 [12:46]  ok, thats pretty soundly defeated. [12:46]  We should make it more prominent that smp_mflags is one of the first things to remove when something is screwy. [12:46] 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] abadger1999: agreed, i'm not opposed to adding text to the smp_mflags item saying that [12:47] and if dwmw2 were here, he'd probably want an smp_flags blocker bug. [12:47] 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] scop: probably. [12:48] but i don't want to say that a motivated maintainer can't do it. [12:48] (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]  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] yeppers. [12:49] any other quick items for today? [12:50] Didn't notting have a proposal? [12:50] Something about moving ldconfig to posttrans? [12:50] I think it had some flaws and is being refined [12:50] I hope it works out. [12:50] %posttrans isn't run on erase-only transactions [12:51] tibbs: not on the schedule or on fedora-packaging [12:51] I suppose talking about perl is out? [12:51] what about perl? [12:52] f13: I saw that in the releng notes... is it really our ball of wax? [12:52] 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] the minimum buildroot is FESCo [12:52] ok, punt to FESCo [12:52] wheee [12:52] fwiw, I think the moon is blue because Ralf and I agree on this one [12:52] * scop giggles [12:53] any other items? [12:53] I can't think of anything. [12:53] but then again, I can't brain today, I have the dumb. [12:54] f13: you own the dumb :) [12:54]  * warren watches the perl issue getting punted to yet another authority [12:54]  *pout* [12:54]  f13: :) [12:54] ok, we're done. i'm going to go put my e10k back together then look for food. [12:54] thanks all.