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
Search

Packaging:Minutes20071030

Contents

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

Present

Writeups

Votes

Other Discussions

IRC Logs
