As you may or may not know I've been unhappy with how the Live image path has diverged from the automated install path (standalone anaconda + @gnome-desktop) for the desktop.
Attached is a series of patches to both comps and spin-kickstarts which has a a high level goal of moving the two closer.
Basically there are 3 fundamentally separate concepts which got intertwined:
* Bits necessary for running a Live OS (turning off cron, etc) * Removing things we do want to fit into a CD * Removing "traditional Unix workstation" or other stuff that @base grew we don't want in @desktop regardless of space
The comps patches come first, then the spin-kickstart patches.
This isn't complete but I think it's a noticeable improvement. We still have more comps gardening to do. Note the spin-kickstart patches obsolete the second of the patch I sent earlier.
From 018bf8e7ca32a45b040b50bde0461d4dac3f9b31 Mon Sep 17 00:00:00 2001 From: Colin Walters walters@verbum.org Date: Tue, 23 Mar 2010 08:47:48 -0400 Subject: [PATCH 1/4] Delete all optional components from @gnome-desktop
Optional components are currently only visible from the UI in Standalone Anaconda, and are a random grab bag of
- Applications
- System administration tools
- Desktop UI replacement
- Other arbitrary software that links to gtk2 and gconf
Unless we start applying this methodology to all the other groups, I would not merge it for the gnome-desktop group.
The other comps patches look OK.
Bill
On Tue, Mar 23, 2010 at 2:29 PM, Bill Nottingham notting@redhat.com wrote:
Unless we start applying this methodology to all the other groups, I would not merge it for the gnome-desktop group.
Fair enough.
The other comps patches look OK.
Applied, thanks!
On Tue, 2010-03-23 at 14:37 -0400, Colin Walters wrote:
On Tue, Mar 23, 2010 at 2:29 PM, Bill Nottingham notting@redhat.com wrote:
Unless we start applying this methodology to all the other groups, I would not merge it for the gnome-desktop group.
Fair enough.
The other comps patches look OK.
Applied, thanks!
I hope you actually did some basic testing of live images and default installs based on these changes before applying them? We're right in the middle of the F13 Beta process and have a base of validation tests built up which becomes somewhat less reliable if major changes to the default package sets start being shoved in...
(remember the law of unintended consequences: even if it seems perfectly obvious that a given package should be taken out, what if that package happened to be the only thing causing some other package that we actually want to be brought in as a dependency, for instance? default package sets are a horribly complex space and I'm not that comfortable with making disruptive changes to them when we're this close to the beta release).
Oh, on the removal of system-config-network: I don't think this is a good idea. NetworkManager is still not capable of configuring dial-up network connections. Removing s-c-n makes it difficult or impossible to configure a dial-up network connection, I believe.
On Wed, Mar 24, 2010 at 2:12 PM, Adam Williamson awilliam@redhat.com wrote:
I hope you actually did some basic testing of live images and default installs based on these changes before applying them?
I've been using qemu (and yes they boot/run etc.) but not doing livepath installs yet.
They're not really very different remember, and in general I'm only adding packages which were already in @gnome-desktop.
We're right in the middle of the F13 Beta process and have a base of validation tests built up which becomes somewhat less reliable if major changes to the default package sets start being shoved in...
So we're at a crossroads now because of the size overflow. We have to do *something*. Really this has always happened because the live images have been an afterthought in the development process.
I've been mostly trying to change things so that in the end the package set is very close; the scanner was the one exception. Actually to keep things clear I'll just punt that to F14.
Oh, on the removal of system-config-network: I don't think this is a good idea. NetworkManager is still not capable of configuring dial-up network connections. Removing s-c-n makes it difficult or impossible to configure a dial-up network connection, I believe.
Remember that system-config-network has not been in the live path install for at least the last release, only in Standalone Anaconda.
On Tue, Mar 23, 2010 at 5:23 PM, Colin Walters walters@verbum.org wrote:
As you may or may not know I've been unhappy with how the Live image path has diverged from the automated install path (standalone anaconda
- @gnome-desktop) for the desktop.
Attached is a series of patches to both comps and spin-kickstarts which has a a high level goal of moving the two closer.
Basically there are 3 fundamentally separate concepts which got intertwined:
- Bits necessary for running a Live OS (turning off cron, etc)
- Removing things we do want to fit into a CD
- Removing "traditional Unix workstation" or other stuff that @base
grew we don't want in @desktop regardless of space
The comps patches come first, then the spin-kickstart patches.
Speaking of changes to comps for the desktop I think it would be worthwhile breaking down the hardware support group into a couple of groups. I was thinking something along the lines of Servers (for iSCSI/FCoE/FCA etc), Desktop/Laptop (For wifi etc), Printing and possibly "other". Things like printers for example with the new auto printer support shouldn't need to be installed by default, you don't want server stuff on a netbook and generally wouldn't need wifi firmwares on a server.
Peter
On Thu, Mar 25, 2010 at 4:40 PM, Peter Robinson pbrobinson@gmail.com wrote:
Speaking of changes to comps for the desktop I think it would be worthwhile breaking down the hardware support group into a couple of groups. I was thinking something along the lines of Servers (for iSCSI/FCoE/FCA etc), Desktop/Laptop (For wifi etc), Printing and possibly "other". Things like printers for example with the new auto printer support shouldn't need to be installed by default, you don't want server stuff on a netbook and generally wouldn't need wifi firmwares on a server.
That makes sense, yes. I think it'd be good to at least have an explicit "server stuff" group. I wanted to call it @traditional-unix-server for stuff like smartmontools and iscsi, but other naming suggestions welcomed.
Colin Walters (walters@verbum.org) said:
Speaking of changes to comps for the desktop I think it would be worthwhile breaking down the hardware support group into a couple of groups. I was thinking something along the lines of Servers (for iSCSI/FCoE/FCA etc), Desktop/Laptop (For wifi etc), Printing and possibly "other". Things like printers for example with the new auto printer support shouldn't need to be installed by default, you don't want server stuff on a netbook and generally wouldn't need wifi firmwares on a server.
That makes sense, yes. I think it'd be good to at least have an explicit "server stuff" group. I wanted to call it @traditional-unix-server for stuff like smartmontools and iscsi, but other naming suggestions welcomed.
Honestly, I could see exploding it into a variety of smaller, more focused groups. Perhaps I'll whip up a proposal based on some comps files I have lying around here.
Bill
On Thu, Mar 25, 2010 at 10:36 PM, Bill Nottingham notting@redhat.com wrote:
Colin Walters (walters@verbum.org) said:
Speaking of changes to comps for the desktop I think it would be worthwhile breaking down the hardware support group into a couple of groups. I was thinking something along the lines of Servers (for iSCSI/FCoE/FCA etc), Desktop/Laptop (For wifi etc), Printing and possibly "other". Things like printers for example with the new auto printer support shouldn't need to be installed by default, you don't want server stuff on a netbook and generally wouldn't need wifi firmwares on a server.
That makes sense, yes. I think it'd be good to at least have an explicit "server stuff" group. I wanted to call it @traditional-unix-server for stuff like smartmontools and iscsi, but other naming suggestions welcomed.
Honestly, I could see exploding it into a variety of smaller, more focused groups. Perhaps I'll whip up a proposal based on some comps files I have lying around here.
I've spent a little time looking at the hardware side of things and done a basic patch for some of the hardware stuff based on the current rawhide comps file. I've broken it down into network/server/misc for the time being and pushed the print stuff over to its group. More can be done as it was a quick look through. The old hardware-support currently includes all the other groups so there's no real change for current builds overall.
I also noticed that alot of the filesystems group lists are replicated into base. I think base should have the core ext related tools to boot a default Fedora and the other stuff like ntfs should just remain in the filesystems group.
Cheers, Peter
On Wed, Apr 21, 2010 at 7:08 AM, Peter Robinson pbrobinson@gmail.com wrote:
I've spent a little time looking at the hardware side of things and done a basic patch for some of the hardware stuff based on the current rawhide comps file. I've broken it down into network/server/misc for the time being and pushed the print stuff over to its group. More can be done as it was a quick look through. The old hardware-support currently includes all the other groups so there's no real change for current builds overall.
This looks like a good start. I think the way this kind of thing should work in general is that the system detects if you have the hardware, and dynamically installs support for it. We'd need some database mapping things like USB ids to packages. Networking is an exception; we should include as many drivers/tools for networking-related functionality as possible so that the system can be bootstrapped.
Basically: if you have a GPS chip, gypsy gets installed and runs. If you don't, it doesn't.
On Wed, Apr 21, 2010 at 2:40 PM, Colin Walters walters@verbum.org wrote:
On Wed, Apr 21, 2010 at 7:08 AM, Peter Robinson pbrobinson@gmail.com wrote:
I've spent a little time looking at the hardware side of things and done a basic patch for some of the hardware stuff based on the current rawhide comps file. I've broken it down into network/server/misc for the time being and pushed the print stuff over to its group. More can be done as it was a quick look through. The old hardware-support currently includes all the other groups so there's no real change for current builds overall.
This looks like a good start. I think the way this kind of thing should work in general is that the system detects if you have the hardware, and dynamically installs support for it. We'd need some database mapping things like USB ids to packages. Networking is an exception; we should include as many drivers/tools for networking-related functionality as possible so that the system can be bootstrapped.
Well basically the way I've done the first swipe above won't impact anything that just includes @hardware-support as it just includes all groups. Those that want to drop stuff can register specific groups. I was thinking of making hardware-support-network hardware-support-wireless but then realises there was a couple of DSL firmwares in the list. In most cases for a server this would make no difference as servers don't generally have wireless and if there is any wired server ethernet in there I would probably move it to server but I think they're all contained in linux-firmware anyway.
Basically: if you have a GPS chip, gypsy gets installed and runs. If you don't, it doesn't.
Agreed. But in the interim until we get pci/usb id matching I figured this would be a good start.
Is it OK to push it to rawhide, are we too late in the process for F-13 given the default doesn't change any of the standard builds?
Peter
Peter Robinson (pbrobinson@gmail.com) said:
Agreed. But in the interim until we get pci/usb id matching I figured this would be a good start.
Is it OK to push it to rawhide, are we too late in the process for F-13 given the default doesn't change any of the standard builds?
Not for F-13, no matter what.
Bill
On 04/21/2010 09:40 AM, Colin Walters wrote:
On Wed, Apr 21, 2010 at 7:08 AM, Peter Robinson pbrobinson@gmail.com wrote:
I've spent a little time looking at the hardware side of things and done a basic patch for some of the hardware stuff based on the current rawhide comps file. I've broken it down into network/server/misc for the time being and pushed the print stuff over to its group. More can be done as it was a quick look through. The old hardware-support currently includes all the other groups so there's no real change for current builds overall.
This looks like a good start. I think the way this kind of thing should work in general is that the system detects if you have the hardware, and dynamically installs support for it. We'd need some database mapping things like USB ids to packages.
Just brainstorming here, but why not do something like:
Provides: modalias(usb:v03F0p0121d*dc*dsc*dp*ic*isc*ip*)
and make a python module that asks udev/devicekit for modaliases of whatever hardware is installed. anaconda could use that relatively easily to search for packages, and a packagekit (or whatever) plugin could do something similar for the hotplug cases after installation.
On Wed, 2010-04-21 at 09:40 -0400, Colin Walters wrote:
This looks like a good start. I think the way this kind of thing should work in general is that the system detects if you have the hardware, and dynamically installs support for it. We'd need some database mapping things like USB ids to packages.
When doing this, please do the obvious thing and store the match information in modalias format:
atropine:~% modinfo appledisplay | grep alias alias: usb:v05ACp921Dd*dc*dsc*dp*ic03isc*ip00* alias: usb:v05ACp9219d*dc*dsc*dp*ic03isc*ip00* alias: usb:v05ACp9218d*dc*dsc*dp*ic03isc*ip00*
system-config-display uses .xinf files in basically this format (tuple of (alias, driver) one per line) to match video devices to drivers. It works well, which is probably the only thing in s-c-d you can say that about. Sample python code to do the match (please steal):
http://git.fedorahosted.org/git/?p=system-config-display.git;a=blob;f=src/al...
Ideally we work out a way to jam this into rpm Provides.
- ajax
On Wed, 2010-04-21 at 09:40 -0400, Colin Walters wrote:
This looks like a good start. I think the way this kind of thing should work in general is that the system detects if you have the hardware, and dynamically installs support for it. We'd need some database mapping things like USB ids to packages. Networking is an exception; we should include as many drivers/tools for networking-related functionality as possible so that the system can be bootstrapped.
Basically: if you have a GPS chip, gypsy gets installed and runs. If you don't, it doesn't.
I've been banging a gong about something like that for years; right now it's much too hard to know what you're supposed to do to make $RANDOM_GADGET that you just plugged in actually work, but we can hardly install the software for every USB device under the sun by default. There's a clear need for something like this. Really it's just a kind of widget that sits between udev and PackageKit, I think.
On Wed, Apr 21, 2010 at 4:17 PM, Adam Williamson awilliam@redhat.com wrote:
On Wed, 2010-04-21 at 09:40 -0400, Colin Walters wrote:
This looks like a good start. I think the way this kind of thing should work in general is that the system detects if you have the hardware, and dynamically installs support for it. We'd need some database mapping things like USB ids to packages. Networking is an exception; we should include as many drivers/tools for networking-related functionality as possible so that the system can be bootstrapped.
Basically: if you have a GPS chip, gypsy gets installed and runs. If you don't, it doesn't.
I've been banging a gong about something like that for years; right now it's much too hard to know what you're supposed to do to make $RANDOM_GADGET that you just plugged in actually work, but we can hardly install the software for every USB device under the sun by default. There's a clear need for something like this. Really it's just a kind of widget that sits between udev and PackageKit, I think.
Dumb question.... Can't the usb printer autoinstall just be extended to support other hardware? Based on usb/pci ids?
Peter
On 21 April 2010 16:17, Adam Williamson awilliam@redhat.com wrote:
I've been banging a gong about something like that for years; right now it's much too hard to know what you're supposed to do to make $RANDOM_GADGET that you just plugged in actually work, but we can hardly install the software for every USB device under the sun by default. There's a clear need for something like this. Really it's just a kind of widget that sits between udev and PackageKit, I think.
It already exists, and is the GpkHardware GObject that lives in gnome-packagekit. In Fedora we disable it by default, but Suse use it to great affect. Fedora just uses GpkFirmware which intercepts missing firmware requests from the kernel and offers to install the firmware and then soft-replug the device.
The hard bit (and why it's disabled in Fedora) is working out what software needs to be installed for a given bit of hardware. It's really the kind of thing that needs to be added to udev as just a simple rule, and then enabled in gnome-packagekit.
Richard.
On 21 April 2010 16:40, Richard Hughes hughsient@gmail.com wrote:
software needs to be installed for a given bit of hardware. It's really the kind of thing that needs to be added to udev as just a simple rule, and then enabled in gnome-packagekit.
Of course, the packages also need rpm provides. The hard bit is working out from a sysfs path "this is a GPS device" and then gpk can install any software that provides "hardwaresupport(gps)"
Richard.
On Wed, 2010-04-21 at 16:45 +0100, Richard Hughes wrote:
On 21 April 2010 16:40, Richard Hughes hughsient@gmail.com wrote:
software needs to be installed for a given bit of hardware. It's really the kind of thing that needs to be added to udev as just a simple rule, and then enabled in gnome-packagekit.
Of course, the packages also need rpm provides. The hard bit is working out from a sysfs path "this is a GPS device" and then gpk can install any software that provides "hardwaresupport(gps)"
Except that the software for enabling the hardware is most likely different from the software to use the hardware.
As long as only front-end applications have those provides and drag in all the dependencies they need, it would probably be fine. Or you'd need to be able to install them as package sets.
On Wed, 2010-04-21 at 09:40 -0400, Colin Walters wrote:
On Wed, Apr 21, 2010 at 7:08 AM, Peter Robinson pbrobinson@gmail.com wrote:
I've spent a little time looking at the hardware side of things and done a basic patch for some of the hardware stuff based on the current rawhide comps file. I've broken it down into network/server/misc for the time being and pushed the print stuff over to its group. More can be done as it was a quick look through. The old hardware-support currently includes all the other groups so there's no real change for current builds overall.
This looks like a good start. I think the way this kind of thing should work in general is that the system detects if you have the hardware, and dynamically installs support for it. We'd need some database mapping things like USB ids to packages. Networking is an exception; we should include as many drivers/tools for networking-related functionality as possible so that the system can be bootstrapped.
Basically: if you have a GPS chip, gypsy gets installed and runs. If you don't, it doesn't.
Most of the GPS devices you won't be able to detect. 99% of the Bluetooth ones don't use the correct device class because it was too new, most of the serial/USB ones will just show up as serial ports that you would have no idea what's behind them.
All that to save 120k of installed space. If we're going to go down that route, we might as well split out the iPod support in Rhythmbox, or the PulseAudio Bluetooth support.
Peter Robinson (pbrobinson@gmail.com) said:
Honestly, I could see exploding it into a variety of smaller, more focused groups. Perhaps I'll whip up a proposal based on some comps files I have lying around here.
I've spent a little time looking at the hardware side of things and done a basic patch for some of the hardware stuff based on the current rawhide comps file. I've broken it down into network/server/misc for the time being and pushed the print stuff over to its group. More can be done as it was a quick look through. The old hardware-support currently includes all the other groups so there's no real change for current builds overall.
Splitting it by functionality makes a bit more sense; for example, you'd want a 'smart card support', not just merging it in with other hardware stuff.
(Sorry I've let this lie... been way too busy.)
Also, I'm not sure the grouplist construct works as you're trying to use it.
I also noticed that alot of the filesystems group lists are replicated into base. I think base should have the core ext related tools to boot a default Fedora and the other stuff like ntfs should just remain in the filesystems group.
Actually, anaconda will pull in the ones you use for formatting if needed.
Bill
On Wed, Apr 21, 2010 at 3:48 PM, Bill Nottingham notting@redhat.com wrote:
Peter Robinson (pbrobinson@gmail.com) said:
Honestly, I could see exploding it into a variety of smaller, more focused groups. Perhaps I'll whip up a proposal based on some comps files I have lying around here.
I've spent a little time looking at the hardware side of things and done a basic patch for some of the hardware stuff based on the current rawhide comps file. I've broken it down into network/server/misc for the time being and pushed the print stuff over to its group. More can be done as it was a quick look through. The old hardware-support currently includes all the other groups so there's no real change for current builds overall.
Splitting it by functionality makes a bit more sense; for example, you'd want a 'smart card support', not just merging it in with other hardware stuff.
(Sorry I've let this lie... been way too busy.)
Also, I'm not sure the grouplist construct works as you're trying to use it.
OK, I just cut and paste it out of other places in the config file so I may have missed something. Suggestions?
I also noticed that alot of the filesystems group lists are replicated into base. I think base should have the core ext related tools to boot a default Fedora and the other stuff like ntfs should just remain in the filesystems group.
Actually, anaconda will pull in the ones you use for formatting if needed.
So the base shouldn't need any file systems then and it should all just be in the file systems group?
Peter
Peter Robinson (pbrobinson@gmail.com) said:
Splitting it by functionality makes a bit more sense; for example, you'd want a 'smart card support', not just merging it in with other hardware stuff.
(Sorry I've let this lie... been way too busy.)
Also, I'm not sure the grouplist construct works as you're trying to use it.
OK, I just cut and paste it out of other places in the config file so I may have missed something. Suggestions?
Not sure you can make it seamless without just copy&pasting the entire group (which is a bad idea). <grouplist> within <group> is ignored in comps.
Actually, anaconda will pull in the ones you use for formatting if needed.
So the base shouldn't need any file systems then and it should all just be in the file systems group?
Or they shouldn't need to necessarily be in a group at all, possibly. Depends on how you want to get them installed. (For example, dosfstools and perhaps the ntfs tools should be included in a desktop where you're expected to access those sorts of filesystems. reiserfs, not so much.)
Bill
On Wed, Apr 21, 2010 at 4:12 PM, Bill Nottingham notting@redhat.com wrote:
Peter Robinson (pbrobinson@gmail.com) said:
Splitting it by functionality makes a bit more sense; for example, you'd want a 'smart card support', not just merging it in with other hardware stuff.
(Sorry I've let this lie... been way too busy.)
Also, I'm not sure the grouplist construct works as you're trying to use it.
OK, I just cut and paste it out of other places in the config file so I may have missed something. Suggestions?
Not sure you can make it seamless without just copy&pasting the entire group (which is a bad idea). <grouplist> within <group> is ignored in comps.
Ah, I just copied the xfce-software-development as it was small and had what I wanted. What's the proper way to do this then? Looking further down the file the Desktops category looks like it would be what I want.
Actually, anaconda will pull in the ones you use for formatting if needed.
So the base shouldn't need any file systems then and it should all just be in the file systems group?
Or they shouldn't need to necessarily be in a group at all, possibly. Depends on how you want to get them installed. (For example, dosfstools and perhaps the ntfs tools should be included in a desktop where you're expected to access those sorts of filesystems. reiserfs, not so much.)
Again, I was just looking at what's in the comps file already.
Peter
Peter Robinson (pbrobinson@gmail.com) said:
Not sure you can make it seamless without just copy&pasting the entire group (which is a bad idea). <grouplist> within <group> is ignored in comps.
Ah, I just copied the xfce-software-development as it was small and had what I wanted. What's the proper way to do this then? Looking further down the file the Desktops category looks like it would be what I want.
Categories aren't a yum-able object; they're used by anaconda only.
Bill
On Wed, 21 Apr 2010, Bill Nottingham wrote:
Peter Robinson (pbrobinson@gmail.com) said:
Not sure you can make it seamless without just copy&pasting the entire group (which is a bad idea). <grouplist> within <group> is ignored in comps.
Ah, I just copied the xfce-software-development as it was small and had what I wanted. What's the proper way to do this then? Looking further down the file the Desktops category looks like it would be what I want.
Categories aren't a yum-able object; they're used by anaconda only.
Like I said before - categories can be used by any yum api-caller.
but they aren't available to anything using yum from the cli.
import yum my = yum.YumBase() my.setCacheDir() c = my.comps.categories[0] print c Desktop Environments print c.groups ['gnome-desktop', 'sugar-desktop', 'window-managers', 'kde-desktop', 'lxde-desktop', 'moblin-desktop', 'xfce-desktop']
-sv
On Wed, 2010-04-21 at 12:06 -0400, Seth Vidal wrote:
On Wed, 21 Apr 2010, Bill Nottingham wrote:
Peter Robinson (pbrobinson@gmail.com) said:
Not sure you can make it seamless without just copy&pasting the entire group (which is a bad idea). <grouplist> within <group> is ignored in comps.
Ah, I just copied the xfce-software-development as it was small and had what I wanted. What's the proper way to do this then? Looking further down the file the Desktops category looks like it would be what I want.
Categories aren't a yum-able object; they're used by anaconda only.
Like I said before - categories can be used by any yum api-caller.
but they aren't available to anything using yum from the cli.
Something I wrote for someone ages ago:
http://james.fedorapeople.org/yum/plugins/categories.py
...I haven't asked for it to be a package because I don't think it's a good idea, but if someone wants to play with it etc. it's there.
Once upon a time, Colin Walters walters@verbum.org said:
I wanted to call it @traditional-unix-server for stuff like smartmontools and iscsi, but other naming suggestions welcomed.
Not commenting on the naming, but I'd put UPS tools on desktops as well. Lots of people have UPSes attached to home computers, while I only have a single server monitoring an UPS (datacenter with a big UPS and generator, the monitoring is just for Nagios to tell us if there's a problem).
Chris Adams (cmadams@hiwaay.net) said:
Not commenting on the naming, but I'd put UPS tools on desktops as well. Lots of people have UPSes attached to home computers, while I only have a single server monitoring an UPS (datacenter with a big UPS and generator, the monitoring is just for Nagios to tell us if there's a problem).
Desktops, yes. Laptops, not really. (Although doing the groups by form-factors isn't really practical.)
Bill
Bill Nottingham wrote:
Desktops, yes. Laptops, not really. (Although doing the groups by form-factors isn't really practical.)
Laptops kinda have their builtin UPS, unless you're one of those folks who take out the battery when on AC to save charging cycles. :-) So it would indeed be weird to plug them into an external UPS.
Kevin Kofler
-
Adam Jackson -
Adam Williamson -
Bastien Nocera -
Bill Nottingham -
Chris Adams -
Chuck Anderson -
Colin Walters -
James Antill -
Kevin Kofler -
Peter Jones -
Peter Robinson -
Richard Hughes -
Seth Vidal