Re: spin kickstart/minimization cleanups
On Wed, 2010-04-21 at 16:45 +0100, Richard Hughes wrote: > On 21 April 2010 16:40, Richard Hughes 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On Wed, 2010-04-21 at 09:40 -0400, Colin Walters wrote: > On Wed, Apr 21, 2010 at 7:08 AM, Peter Robinson 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On Wed, 2010-04-21 at 12:06 -0400, Seth Vidal wrote: > > On Wed, 21 Apr 2010, Bill Nottingham wrote: > > > Peter Robinson (pbrobin...@gmail.com) said: > >>> Not sure you can make it seamless without just copy&pasting the > >>> entire group (which is a bad idea). within > >>> 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. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On Wed, 21 Apr 2010, Bill Nottingham wrote: > Peter Robinson (pbrobin...@gmail.com) said: >>> Not sure you can make it seamless without just copy&pasting the >>> entire group (which is a bad idea). within >>> 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
Peter Robinson (pbrobin...@gmail.com) said: > > Not sure you can make it seamless without just copy&pasting the > > entire group (which is a bad idea). within > > 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On 21 April 2010 16:40, Richard Hughes 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On 21 April 2010 16:17, Adam Williamson 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On Wed, Apr 21, 2010 at 4:12 PM, Bill Nottingham wrote: > Peter Robinson (pbrobin...@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). within > 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On Wed, Apr 21, 2010 at 4:17 PM, Adam Williamson 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
Peter Robinson (pbrobin...@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). within 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On Wed, Apr 21, 2010 at 3:48 PM, Bill Nottingham wrote: > Peter Robinson (pbrobin...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
Peter Robinson (pbrobin...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
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/alias.py;h=c81a7f4653f037e218a6dc449e135f3a93747e62;hb=HEAD Ideally we work out a way to jam this into rpm Provides. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
Peter Robinson (pbrobin...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On 04/21/2010 09:40 AM, Colin Walters wrote: > On Wed, Apr 21, 2010 at 7:08 AM, Peter Robinson 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. -- Peter Hardware simply does not work like the manual says and no amount of Zen contemplation will ever make you at one with a 3c905B ethernet card. -- Alan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On Wed, Apr 21, 2010 at 2:40 PM, Colin Walters wrote: > On Wed, Apr 21, 2010 at 7:08 AM, Peter Robinson 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On Wed, Apr 21, 2010 at 7:08 AM, Peter Robinson 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On Thu, Mar 25, 2010 at 10:36 PM, Bill Nottingham wrote: > Colin Walters (walt...@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 comps-f14.xml.in.patch Description: Binary data -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
Chris Adams (cmad...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
Colin Walters wrote: > Move system-config-lvm to optional > > It's redundant with gnome-disk-utility, and the alternative > desktop UI spins are stripping it out anyways. Uh, no, the KDE spin was not stripping it out. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
Colin Walters wrote: > Several core things depend on info; it just doesn't make sense to have > two info viewers. Except "info" is a royal PITA to use, pinfo was written for a reason! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
Once upon a time, Colin Walters 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 Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
Colin Walters (walt...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On Thu, Mar 25, 2010 at 4:40 PM, Peter Robinson 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On Tue, Mar 23, 2010 at 5:23 PM, Colin Walters 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On Wed, Mar 24, 2010 at 2:12 PM, Adam Williamson 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On Tue, 2010-03-23 at 14:37 -0400, Colin Walters wrote: > On Tue, Mar 23, 2010 at 2:29 PM, Bill Nottingham 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On Tue, Mar 23, 2010 at 02:11:23PM -0400, Colin Walters wrote: > - system-config-network > + system-config-network Thank you :-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On Tue, Mar 23, 2010 at 2:29 PM, Bill Nottingham 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! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
> From 018bf8e7ca32a45b040b50bde0461d4dac3f9b31 Mon Sep 17 00:00:00 2001 > From: Colin Walters > 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
A few more comps patches. From 69838cdd1765fa07df5482862c365058880a975f Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Tue, 23 Mar 2010 13:34:53 -0400 Subject: [PATCH 1/3] Move system-config-network to optional We're moving the OS towards NetworkManager. --- comps-f13.xml.in |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/comps-f13.xml.in b/comps-f13.xml.in index c0b33e2..32d233f 100644 --- a/comps-f13.xml.in +++ b/comps-f13.xml.in @@ -16,7 +16,6 @@ system-config-keyboard system-config-language system-config-lvm - system-config-network system-config-users cacti dbench @@ -32,6 +31,7 @@ ntop pessulus qtparted + system-config-network system-config-kickstart system-config-rootpassword yumex -- 1.6.6.1 From 8dce2a9d49a2716ac5d10d2d9a5c92ee84e8a7d4 Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Tue, 23 Mar 2010 13:48:13 -0400 Subject: [PATCH 2/3] Move system-config-lvm to optional It's redundant with gnome-disk-utility, and the alternative desktop UI spins are stripping it out anyways. --- comps-f13.xml.in |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/comps-f13.xml.in b/comps-f13.xml.in index 32d233f..219fa51 100644 --- a/comps-f13.xml.in +++ b/comps-f13.xml.in @@ -15,7 +15,6 @@ system-config-firewall system-config-keyboard system-config-language - system-config-lvm system-config-users cacti dbench @@ -33,6 +32,7 @@ qtparted system-config-network system-config-kickstart + system-config-lvm system-config-rootpassword yumex -- 1.6.6.1 From fd525bc909e727578503b45c9ff99b3d4bf6760f Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Tue, 23 Mar 2010 14:05:44 -0400 Subject: [PATCH 3/3] Add PackageKit-command-not-found to @gnome-desktop --- comps-f13.xml.in |1 + comps-f14.xml.in |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/comps-f13.xml.in b/comps-f13.xml.in index 219fa51..96c2f0a 100644 --- a/comps-f13.xml.in +++ b/comps-f13.xml.in @@ -2631,6 +2631,7 @@ NetworkManager-vpnc notification-daemon orca + PackageKit-command-not-found pulseaudio-module-gconf pulseaudio-module-x11 preupgrade diff --git a/comps-f14.xml.in b/comps-f14.xml.in index f67f31f..acf193b 100644 --- a/comps-f14.xml.in +++ b/comps-f14.xml.in @@ -2627,6 +2627,7 @@ NetworkManager-vpnc notification-daemon orca + PackageKit-command-not-found pulseaudio-module-gconf pulseaudio-module-x11 seahorse -- 1.6.6.1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
