Packaging:Minutes20071030

Present

 * DavidLutterkort
 * JasonTibbitts
 * JesseKeating
 * RexDieter
 * TomCallaway
 * ToshioKuratomi

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