Packaging:Minutes20071030

Fedora Packaging Committee Meeting of {2007-10-30}

Present

• DavidLutterkort (lutter)
• JasonTibbitts (tibbs)
• JesseKeating (f13)
• RexDieter (rdieter)
• TomCallaway (spot)
• ToshioKuratomi (abadger1999)

Writeups

No new guidelines this week.

Votes

The following proposals were considered:

• Specifying the root directory for LTSP as /var/lib/ltsp
• Not yet accepted (4 - 0)
• Voting for: abadger1999 rdieter spot tibbs
• Voting is still open on-list

• Standardizing the set of virtual provides for various servers: http://fedoraproject.org/wiki/PackagingDrafts/ServerProvides
• Accepted (5 - 0)
• Voting for: spot rdieter abadger1999 tibbs f13
• There is still tweaking to be done, and because this will require changes to several packages, FPC is asking that this be driven via the feature process for F-9.

• Specifying the location for Fortran 90 .mod files: http://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir
• Accepted (5 - 0)
• Voting for: spot rdieter f13 abadger1999 tibbs

Other Discussions

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

• Acceptability of metapackages.

IRC Logs

[11:01]  * spot will be right back
[11:01]  <spot> need more water
[11:07]  --> lutter has joined this channel (n=dlutter@dsl081-244-080.sfo1.dsl.speakeasy.net).
[11:10]  <spot> lutter: hi.
[11:10]  <tibbs> Off the phone now but still distracted; my grandmother is in ICU.
[11:10]  <lutter> spot: howdy
[11:10]  <spot> tibbs: sorry to hear that
[11:10]  <tibbs> Thanks.
[11:10]  <spot> f13 got pulled into the board meeting, won't be attending today
[11:11]  <lutter> spot: are we doing the meeting now ? If so, I managed to schedule myself into a conflict
[11:11]  <spot> abadger1999, rdieter?
[11:11]  <spot> lutter: we're supposed to be doing it now. :)
[11:11]  <abadger1999> pong
[11:11]  <rdieter> here
[11:12]  <spot> we barely have quorum, i count 5.
[11:13]  <spot> So, lets try to knock some of the easy stuff through. :)
[11:13]  <spot> I propose that we make /var/lib/ltsp be the root directory for LTSP
[11:13]  <abadger1999> +1
[11:13]  <rdieter> +1
[11:13]  <spot> +1
[11:14]  <tibbs> Does anyone know how large that's expected to be?
[11:14]  <abadger1999> The /opt placement has been a thorn since forever
[11:14]  <abadger1999> tibbs: Big.
[11:14]  <abadger1999> tibbs: The ltsp clients run diskless... The root filesystem is under the ltsp hierarchy.
[11:15]  <tibbs> +1 in any case, although it would be super-nice if our packaging allowed it to be moved easily.
[11:15]  <spot> lutter: if you're still here, we do need you to vote. :)
[11:18]  <spot> hmm.
[11:18]  <spot> well, without lutter, we don't have quorum.
[11:19]  <abadger1999> Do we want to see what we can get four votes on and take it to the list for the last vote for them?
[11:19]  <spot> abadger1999: sure.
[11:19]  <spot> the only other issue i am aware of is: http://fedoraproject.org/wiki/PackagingDrafts/ServerProvides
[11:20]  <spot> essentially, this would replace the "Provides: webserver" with "Provides: server(httpd)", according to the names in /etc/services
[11:20]  <tibbs> This would be very nice to have, I think.
[11:20]  <spot> I think so too.
[11:21]  <spot> I
[11:21]  <spot> err, rather, I'll +1 it.
[11:21]  <rdieter> server(httpd) vs service(httpd)?
[11:21]  <tibbs> Of course, we can't just remove the Provides: webserver but having a nice standard for naming these would be nice.
[11:21]  <spot> server(port_name)
[11:22]  <rdieter> wouldn't using 'service' make more sense?
[11:22]  <rdieter> or I guess it doesn't matter all that much
[11:22]  <rdieter> +1 to whatever.
[11:22]  <spot> rdieter: i believe the eventual extension is to have "client(port_name)"
[11:22]  <abadger1999> Looks good to me.
[11:23]  <abadger1999> +1
[11:23]  <spot> but thats beyond the scope of this draft.
[11:23]  <rdieter> makes even more sense now.
[11:23]  * spot sees +3
[11:23]  <tibbs> +1
[11:23]  <spot> +4.
[11:23]  <spot> ok, are there any other items?
[11:24]  <spot> (if not, please say no)
[11:24]  <tibbs> There was one other thing floated on-list.
[11:24]  <abadger1999> Fortran mods
[11:24]  <tibbs> metapackages.
[11:24]  <abadger1999> tibbs: Go ahead and go first.
[11:25]  <spot> so, metapackages. i'd like to avoid these wherever possible.
[11:25]  <tibbs> nim-nim had proposed that we regulate metapackages.  I think he wants us to ban them.
[11:25]  <f13> oh god, please.
[11:25]  <tibbs> I think there are cases where they're appropriate.
[11:26]  <rdieter> over regulation bad, mm-kay?
[11:26]  <tibbs> At least, I have reviewed and approved at least one metapackage.
[11:26]  <f13> I think most metapackage needs can be solved with appropriate comps groups.
[11:26]  <tibbs> Take the Horde web-applications.
[11:26]  <tibbs> They have tons of optional modules which many users want pulled in.
[11:27]  <tibbs> I approved a horde-full metapackage.  Works great for that in my experience.
[11:27]  <f13> why can't there be a Hord group in the Servers category that has the defaults/options listed?
[11:27]  <f13> metapackages are somewhat lame for discovery
[11:27]  <rdieter> koffice-suite is another currrent example
[11:27]  <f13> rdieter: again, comps group?
[11:28]  <tibbs> It gives two completely different interfaces for installing something.
[11:28]  <rdieter> f13: sure, possible, I'm just mentioning another example.
[11:28]  <spot> it would be nice to have consistency, afaik, neither comps groups nor metapackages are documented
[11:28]  <tibbs> I want to install the koffice suite.  What do I "yum install"?
[11:28]  <f13> tibbs: completely different?
[11:28]  <f13> tibbs: yum groupinstall koffice
[11:28]  <tibbs> Oh, I yum groupinstall.  Why are some things groups and some things not?
[11:29]  <f13> because somethings are more than one package, and some arn't.
[11:29]  <f13> why can't I just 'yum install gnome' ?
[11:29]  <f13> non-argument.
[11:29]  <tibbs> Most things are more than one package, though; yum installs them for me just fine using dependencies.
[11:29]  <f13> because those are real deps
[11:29]  * spot idly wonders if someone could enable something like yum install group.koffice
[11:29]  <f13> you're trying to solve the lack of Suggests with meta packages.
[11:29]  <tibbs> Like I said, I have no specific issues with metapackages.
[11:30]  <tibbs> Groups don't seem to handle package splits, and I can't see which groups I have installed because that's not tracked anywhere.
[11:31]  <f13> yum grouplist
[11:31]  <rdieter> I suppose we could at least "encourage" use of comps over metapackages.  that makes some sense.
[11:31]  <f13> Add Remove software shows the groups installed too
[11:31]  <f13> tibbs: and define 'handle package splits' ?
[11:31]  <tibbs> I've never used that; I just use yum and rpm.
[11:31]  <f13> tibbs: and you can do it with yum.
[11:32]  <tibbs> koffice-calc splits into koffice-calc and koffice-calc-templates or something.
[11:32]  <f13> tibbs: comps can be edited to reflect that.
[11:32]  <tibbs> But does the new package get installed or does the functionality just disappear from my system when I update?
[11:33]  <rdieter> tibbs: depending on how you update
[11:33]  <rdieter> tibbs: yum update vs yum groupinstall koffice
[11:33]  <f13> a split like that should be accompanied by a Requires.
[11:33]  <tibbs> So now you see the issue.
[11:33]  <f13> because what if this was installed outside the metapackage?
[11:33]  <f13> relying on metapackages for this is /wrong/.
[11:33]  <rdieter> and carefull use of Obsoletes/Requires.
[11:34]  <tibbs> If I installed the metapackage, I obviously want all the packages in that umbrella.  If yum can keep all of a group installed even when things are added to that group, then fine.
[11:34]  <rdieter> f13: it may be /wrong/, but it "just works",  whereas comps has ways of failing currently
[11:34]  <f13> it doesn't Just Work
[11:34]  <tibbs> But if I have to keep groupinstall-ing everything to keep the groups installed, then I still see a need for metapackages.
[11:34]  <f13> because if you installed these bits outside the metapackage, which you certainly can do, you don't get the new bits.
[11:34]  <rdieter> f13: it works by tibbs criteria/definiting of working anyway
[11:35]  <rdieter> definition even
[11:35]  <tibbs> The problem is that I have to deal with this currently, and I use groups, and it sucks for my application.
[11:35]  <rdieter> to me, it appears folks want metapackages mostly as bandaids for shortcomings of comps/group handling.
[11:35]  <f13> or the lack of Suggests in rpm.
[11:36]  <rdieter> that too.
[11:36]  <tibbs> But we hate Suggests, right?
[11:36]  <f13> no
[11:36]  <rdieter> not me
[11:36]  <pembo13_com> suggests should be implemented alongside, but not part of rpm
[11:36]  <f13> we're just not ready to throw it at the infrastructure.
[11:36]  <pembo13_com> well maybe not _should_ but _could_
[11:36]  <f13> pembo13_com: that would be comps.
[11:36]  <tibbs> Well that's a change in opinion from when it was first added to rpm.
[11:37]  <f13> pembo13_com: the problem being is that you group install somethign today, contents of the group changes tomorrow, yum updates won't reflect any change.
[11:37]  <rdieter> nod
[11:37]  <f13> tibbs: I'm sure some people have the same opinion as then.
[11:37]  <f13> IE if it's suggested, just make it Require and be done with it.
[11:37]  <spot> i think it would be better to focus on fixing the issues in yum groups before banning metapackages.
[11:37]  <f13> but I think we can reach a point where we have a reasonable default (suggests are always pulled in) and the ability to adjust this for people who care.
[11:38]  <pembo13_com> f13, i've envisioned a suggests like system implemented at the UI level
[11:38]  <rdieter> one reason we use yum-updatesonboot for sw deployment here (it updates groups too)
[11:38]  <f13> pembo13_com: have you looked at add/remove software and the group listings?
[11:38]  <f13> pembo13_com: you know, where there are mandatory packages in a group, default ones pre-selected, and optional ones not selected?
[11:38]  <pembo13_com> f13, i hate the look, but haven't had time to mockup anything better
[11:39]  <f13> spot: I don't disagree, I just don't want to push forward the idea of metapackages as the solution to all oru problems.
[11:39]  <pembo13_com> f13, i rarely use it
[11:39]  <f13> pembo13_com: PackageKit will surely fix this.
[11:39]  <pembo13_com> f13, how so?
[11:39]  <abadger1999> So the issue is metapackages allow you to install everything in the group even when the packages in the group grows; comps allows you to install once, customize (ie: remove leaf packages and be done).  We'd like comps to handle both modes of operation.
[11:39]  <pembo13_com> how new is #fedora-kde?
[11:39]  <spot> abadger1999: +1
[11:40]  <spot> this sounds more like something to be tracked as an F9 Feature
[11:40]  <tibbs> abadger1999: +1 "sticky groups" or somesuch.
[11:40]  <f13> pembo13_com: unified UI for dealing with software and packages.
[11:41]  <f13> pembo13_com: done at say gnome and/or KDE rather than reinvented in each distro for each packaging system.
[11:41]  <pembo13_com> f13, i see, and writeups anywhere?
[11:41]  <pembo13_com> any*
[11:41]  <f13> pembo13_com: google for PackageKit, lots of work going on.
[11:41]  <rdieter> http://www.packagekit.org/
[11:42]  <f13> abadger1999: the problem I see is how to you handle "an optional package was added to the group' vs "a default package was added to the group"?  Obviously a mandatory package added to the group would get pulled in.
[11:42]  <spot> ok, so i think we've beaten this one into the ground, fortran mods was the other topic?
[11:42]  <abadger1999> https://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir
[11:42]  <pembo13_com> rdieter, thanks
[11:43]  <pembo13_com> that site reminds me of gnome
[11:43]  <abadger1999> f13: That is an additional wrinkle in comps... there's no such distinction in a metapackage.
[11:43]  <spot> fwiw, i'm fine the FortranModulesDir draft. +1
[11:43]  <spot> fine with the, rather.
[11:43]  <rdieter> fmod +1
[11:44]  <f13> abadger1999: right, I feel that any sort of "policy" we create for dealing with this in comps will naturally fit into policy for dealing with this in Suggests: within rpm.
[11:44]  <f13> +1 from me, it seemed sane and it's a policy.
[11:44]  <abadger1999> So it should be solvable separately --> ie: initial implementation could deal only with default packages.  later implementatoin could decide what to do with optionals.
[11:44]  <abadger1999> +1 fortran mod dir.
[11:44]  <tibbs> +1
[11:45]  <spot> ok, thats +5 for fortran mod dir
[11:45]  <spot> f13: since you're here now
[11:45]  <spot> http://fedoraproject.org/wiki/PackagingDrafts/ServerProvides
[11:45]  <f13> uh oh
[11:45]  <spot> we have a +4 on that
[11:45]  * f13 reads
[11:45]  <pembo13_com> well the PackageKit concept seems very good
[11:45]  <spot> Also, let /var/lib/ltsp be the root directory for LTSP has a +4 vote
[11:46]  <f13> So I don't see anything in that proposal that talks about how this would interact with Alternatives, if at all.
[11:46]  <spot> f13: its just a replacement for arbitrary naming in Provides
[11:46]  <spot> f13: instead of Provides: foobargoldfish
[11:46]  <f13> so I'm Ok with moving to a more standard foo(bar) type require listing, but would be nice to at least investigate how it might interact with alternatives.
[11:47]  <spot> uhh, i'm not sure how it is relevant
[11:47]  <f13> spot: I don't think it's completely arbitrary, I think it matched the Alternatives name.
[11:47]  <f13> or if it didn't, we could try to make the alternatives name comply here too, so that the provide is common throughout the system.
[11:48]  <spot> f13: i don't think httpd was using "webserver" for alternatives
[11:48]  <f13> spot: I was thinking more of the mail server example.  but I'd have to look.
[11:49]  <abadger1999> f13: alternatives appears to use mta rather than smtpdaemon.
[11:49]  <f13> also missing is any indication as to A) whom is going to do the changes, B) how they're going to be tracked, C) a deadline for the changes
[11:49]  <f13> abadger1999: so would it not make sense to update Alternatives definitions at the same time?
[11:49]  <spot> f13: ideally, A, B, C would be defined as a feature, not a packaging guideline
[11:49]  <f13> if we're complaining about consistancy, might as well be consistant.
[11:49]  <abadger1999> Yep.  It would be nice to make things match across the board.
[11:50]  <f13> spot: sure, but I don't want to introduce a guideline without any plans for how it would effect the current packages that would fail.
[11:50]  <abadger1999> Although alternatives is a bit different from this.
[11:50]  <abadger1999> For instance, java is in alternatives but plainly won't be in here.
[11:50]  <spot> does anyone want to drive this issue?
[11:50]  <abadger1999> And server(httpd) will be here but not in alternatives.
[11:51]  <abadger1999> In fact, smtpdaemon is the only thing I see in my local Alternatives that would be a cross-over candidate.
[11:53]  <abadger1999> So... I think I'd leave alternatives out of it.
[11:53]  <spot> well, perhaps we should tell Patrice that we'd like to see an F-9 feature for implementing this change
[11:53]  <spot> he seems motivated, i suspect he's willing to do that.
[11:53]  <f13> nod
[11:54]  <abadger1999> spot: I think that's reasonable if we can also tell him that we will ratify the guideline with his feature plan for moving it forward.
[11:54]  <spot> abadger1999: well, that's really up to f13. ;)
[11:55]  <abadger1999> because we've been telling people (like Harald hoyer's lsb initscript feature proposal) to get things to the packaging committee first, then try to make changes to packages.
[11:55]  <spot> yep.
[11:56]  <spot> i think we can always revisit it if no one drives the feature
[11:56]  <f13> I'm OK with approving it so long as we have the starting of a plan on how to fix current packages.
[11:56]  <pembo13_com> what do you guys use to to virtualise for testing KDE?
[11:56]  <f13> (and not just a terse bug report spammed out to all effected packages)
[11:57]  <spot> f13: is that a "+1, now make a feature for f9!"
[11:57]  <f13> pembo13_com: kvm, qemu, xen, extra hardware
[11:57]  <f13> spot: sure!
[11:57]  <tibbs> To be fair, it doesn't really require changes to all that many packages.
[11:57]  <pembo13_com> f13, i know the options, but do you use all 4?
[11:58]  <f13> I use kvm (which uses qemu) as well as extra hardware.
[11:58]  <pembo13_com> f13, okay
[11:59]  <spot> ok, that should be everything for today
[11:59]  <spot> any other items?
[11:59]  <tibbs> We have a time change coming up.
[12:00]  <tibbs> For the US at least.
[12:00]  <rdieter> kde-sig meeting is here, now. :)
[12:00]  <tibbs> Just to be clear, the next FPC meeting is stil at 16:00UTC.
[12:02]  <spot> thanks all.
[12:02]  * spot goes to find food