Hi,
Please see bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174092
It seems that with Everything install option gone in FC5 test1, one cannot install all packages from CD. I'm still downloading it so I cannot test by myself yet, but Jeremy's reply suggests it won't be added back (how are the package groups handled with multiple repositories?).
In previous Fedora versions, there was also the Details button for a package group, is this gone too? There one could have manually selected additional packages, and this is a solution.
If both these options are gone, then should the packages which aren't installed by default if all groups are selected be moved to Fedora Extras?
Thanks,
On Fri, Nov 25, 2005 at 11:56:01PM +0200, Marius Andreiana wrote:
In previous Fedora versions, there was also the Details button for a package group, is this gone too? There one could have manually selected additional packages, and this is a solution. If both these options are gone, then should the packages which aren't installed by default if all groups are selected be moved to Fedora Extras?
Did you notice the big disclaimer? The screen isn't done yet?
On Fri, 2005-11-25 at 23:56 +0200, Marius Andreiana wrote:
It seems that with Everything install option gone in FC5 test1, one cannot install all packages from CD. I'm still downloading it so I cannot test by myself yet, but Jeremy's reply suggests it won't be added back (how are the package groups handled with multiple repositories?).
Everything is a bit of a disaster in a lot of ways. Some people think that it shouldn't include language-specific packages. Some people think it should. With multiple repositories, should it include all of the packages from all of the repositories? What happens if there are conflicts? And that's in addition to mattdm's helpful comments in the bug :)
In previous Fedora versions, there was also the Details button for a package group, is this gone too? There one could have manually selected additional packages, and this is a solution.
As the screen says, it's just a temporary placeholder for now :) Details will be coming back, although not exactly as it was before.
If both these options are gone, then should the packages which aren't installed by default if all groups are selected be moved to Fedora Extras?
In a lot of cases, packages which aren't listed in the comps file at all (or aren't a dependency of something) perhaps _should_ move to Extras. In addition, I think there probably are packages which should move somewhere into the comps file. File bugs against comps for things that should be listed and aren't.
Jeremy
In a lot of cases, packages which aren't listed in the comps file at all (or aren't a dependency of something) perhaps _should_ move to Extras. In addition, I think there probably are packages which should move somewhere into the comps file. File bugs against comps for things that should be listed and aren't.
Shouldn't we start to accept also comps files for addon repositories? We could also allow newer comps files in the updates repositories.
This would allow some more flexibility...
regards,
Florian La Roche
On 11/26/05, Jeremy Katz katzj@redhat.com wrote:
On Fri, 2005-11-25 at 23:56 +0200, Marius Andreiana wrote:
It seems that with Everything install option gone in FC5 test1, one cannot install all packages from CD. I'm still downloading it so I cannot test by myself yet, but Jeremy's reply suggests it won't be added back (how are the package groups handled with multiple repositories?).
Everything is a bit of a disaster in a lot of ways. Some people think that it shouldn't include language-specific packages. Some people think it should. With multiple repositories, should it include all of the packages from all of the repositories? What happens if there are conflicts? And that's in addition to mattdm's helpful comments in the bug :)
In previous Fedora versions, there was also the Details button for a package group, is this gone too? There one could have manually selected additional packages, and this is a solution.
As the screen says, it's just a temporary placeholder for now :) Details will be coming back, although not exactly as it was before.
If both these options are gone, then should the packages which aren't installed by default if all groups are selected be moved to Fedora Extras?
In a lot of cases, packages which aren't listed in the comps file at all (or aren't a dependency of something) perhaps _should_ move to Extras. In addition, I think there probably are packages which should move somewhere into the comps file. File bugs against comps for things that should be listed and aren't.
I've opened bug #174244 on comps and attached a list of all the rpms that did not get installed. This list contains 999 rpms! Something is seriously wrong here...
Best regards, Bernd.
On 11/26/2005 12:50:26 AM, Jeremy Katz wrote:
On Fri, 2005-11-25 at 23:56 +0200, Marius Andreiana wrote:
It seems that with Everything install option gone in FC5 test1, one cannot install all packages from CD. I'm still downloading it so I cannot test by myself yet, but Jeremy's reply suggests it won't be added back (how are the package groups handled with multiple repositories?).
Everything is a bit of a disaster in a lot of ways. Some people think that it shouldn't include language-specific packages. Some people think it should. With multiple repositories, should it include all of the packages from all of the repositories? What happens if there are conflicts? And that's in addition to mattdm's helpful comments in the bug :)
That one is solvable by calling it "everything from core" and having a follow-up dialog to select language(s)...
As if you didn't have enough to do :-)
Regards, Willem Riede.
On Sat, Nov 26, 2005 at 02:32:17PM +0000, Willem Riede wrote:
that it shouldn't include language-specific packages. Some people think it should. With multiple repositories, should it include all of the packages from all of the repositories? What happens if there are
That one is solvable by calling it "everything from core" and having a
[...]
But if it is just "everything from core", what's the argument for having it, then? From what I've heard from people who like having Everything, they want it because they want every possibility pre-installed -- which this wouldn't be. It'd just be "a bunch of stuff that's useful in a core distribution, the majority of which isn't ever going to be useful or relevant to any one specific installation".
On 11/26/2005 10:35:27 AM, Matthew Miller wrote:
On Sat, Nov 26, 2005 at 02:32:17PM +0000, Willem Riede wrote:
that it shouldn't include language-specific packages. Some people think it should. With multiple repositories, should it include all of the packages from all of the repositories? What happens if there are
That one is solvable by calling it "everything from core" and having a
[...]
But if it is just "everything from core", what's the argument for having it, then? From what I've heard from people who like having Everything, they want it because they want every possibility pre-installed -- which this wouldn't be. It'd just be "a bunch of stuff that's useful in a core distribution, the majority of which isn't ever going to be useful or relevant to any one specific installation".
Having "everything from every repo that I identified" installed is not a safe option to provide. Many repos hold updates to core packages that should not be blindly chosen.
And frankly, I'd vote for not having an everything option at all, because your qualification of the majority not being useful or relevant to the user defenitely holds independant of how wide an everything net you cast.
The only reason users go for it IMHO is that they they don't know what they want or need. They end up with stuff installed they don't know they have, even though they might use it if they knew. With yum it is so easy and convenient to just pull in a package that you want to try once you learn about its existance, that I don't see the value of speculatively pre-installing.
But if there is going to be an "everything", again IMHO, it should be limited to core.
Regards, Willem Riede.
On Sat, 2005-11-26 at 16:02 +0000, Willem Riede wrote:
On 11/26/2005 10:35:27 AM, Matthew Miller wrote:
On Sat, Nov 26, 2005 at 02:32:17PM +0000, Willem Riede wrote:
that it shouldn't include language-specific packages. Some people think it should. With multiple repositories, should it include all of the packages from all of the repositories? What happens if there are
That one is solvable by calling it "everything from core" and having a
[...]
But if it is just "everything from core", what's the argument for having it, then? From what I've heard from people who like having Everything, they want it because they want every possibility pre-installed -- which this wouldn't be. It'd just be "a bunch of stuff that's useful in a core distribution, the majority of which isn't ever going to be useful or relevant to any one specific installation".
Having "everything from every repo that I identified" installed is not a safe option to provide. Many repos hold updates to core packages that should not be blindly chosen.
And frankly, I'd vote for not having an everything option at all, because your qualification of the majority not being useful or relevant to the user defenitely holds independant of how wide an everything net you cast.
The only reason users go for it IMHO is that they they don't know what they want or need. They end up with stuff installed they don't know they have, even though they might use it if they knew. With yum it is so easy and convenient to just pull in a package that you want to try once you learn about its existance, that I don't see the value of speculatively pre-installing.
But if there is going to be an "everything", again IMHO, it should be limited to core.
yum --disablerepo='*' --enablerepo='base' --enablerepo='updates-released' install '*'
that would be an 'install everything, just from core'
-sv
On Sat, 2005-11-26 at 14:32 +0000, Willem Riede wrote:
On 11/26/2005 12:50:26 AM, Jeremy Katz wrote:
On Fri, 2005-11-25 at 23:56 +0200, Marius Andreiana wrote:
It seems that with Everything install option gone in FC5 test1, one cannot install all packages from CD. I'm still downloading it so I cannot test by myself yet, but Jeremy's reply suggests it won't be added back (how are the package groups handled with multiple repositories?).
Everything is a bit of a disaster in a lot of ways. Some people think that it shouldn't include language-specific packages. Some people think it should. With multiple repositories, should it include all of the packages from all of the repositories? What happens if there are conflicts? And that's in addition to mattdm's helpful comments in the bug :)
That one is solvable by calling it "everything from core" and having a follow-up dialog to select language(s)...
As if you didn't have enough to do :-)
here's an idea - rather than having all this stuff in anaconda, why not just install a 'workstation' or 'minimal' system. boot it up then run: yum install '*'
to your little hearts content.
Then you can clutter up your own system as much as you want w/o having to add confusing features and useless buttons into anaconda.
-sv
On Sat, Nov 26, 2005 at 12:50:26AM -0500, Jeremy Katz wrote:
In a lot of cases, packages which aren't listed in the comps file at all (or aren't a dependency of something) perhaps _should_ move to Extras. In addition, I think there probably are packages which should move somewhere into the comps file. File bugs against comps for things that should be listed and aren't.
How about making Anaconda always only do a minimal install, and make firstboot have the option to install other things if you want 'em? :)
On Sat, 2005-11-26 at 09:39 -0500, Matthew Miller wrote:
On Sat, Nov 26, 2005 at 12:50:26AM -0500, Jeremy Katz wrote:
In a lot of cases, packages which aren't listed in the comps file at all (or aren't a dependency of something) perhaps _should_ move to Extras. In addition, I think there probably are packages which should move somewhere into the comps file. File bugs against comps for things that should be listed and aren't.
How about making Anaconda always only do a minimal install, and make firstboot have the option to install other things if you want 'em? :)
Because that gets into non-fun questions about whether or not to install X and a desktop as part of "minimal". And my answer definitely differs from that of a number of people :)
Jeremy
On Sat, Nov 26, 2005 at 10:36:55AM -0500, Jeremy Katz wrote:
How about making Anaconda always only do a minimal install, and make firstboot have the option to install other things if you want 'em? :)
Because that gets into non-fun questions about whether or not to install X and a desktop as part of "minimal". And my answer definitely differs from that of a number of people :)
True. Okay, so, minimal + the minimum X required to install firstboot with a package chooser. With an option to do *just* minimal for experts. :)
On 11/26/05, Matthew Miller mattdm@mattdm.org wrote:
True. Okay, so, minimal + the minimum X required to install firstboot with a package chooser. With an option to do *just* minimal for experts. :)
How about the "experts" use kickstart files to do pretty much any pre-install configuration that the dependancy chains allow?
-jef"Could the wiki be used to hold community contributed kickstart files?"spaleta
On Sat, Nov 26, 2005 at 10:48:40AM -0500, Jeff Spaleta wrote:
On 11/26/05, Matthew Miller mattdm@mattdm.org wrote:
True. Okay, so, minimal + the minimum X required to install firstboot with a package chooser. With an option to do *just* minimal for experts. :)
How about the "experts" use kickstart files to do pretty much any pre-install configuration that the dependancy chains allow?
'Cause it's a pain to create a kickstart file to install just one server system.
On 11/26/05, Matthew Miller mattdm@mattdm.org wrote:
'Cause it's a pain to create a kickstart file to install just one server system.
Its also a pain to create your own distro for one server system. You missed my point.... can't this community create a variety of useful kickstart files and SHARE THEM? Surely there are have to be a cononical collection of kickstart files that more than one person in this community would like to use? Certaintly one example of such a kickstart file is equilalent to whatever anaconda could provide as a "minimal" install.
-jef
On Sat, 2005-11-26 at 10:44 -0500, Matthew Miller wrote:
On Sat, Nov 26, 2005 at 10:36:55AM -0500, Jeremy Katz wrote:
How about making Anaconda always only do a minimal install, and make firstboot have the option to install other things if you want 'em? :)
Because that gets into non-fun questions about whether or not to install X and a desktop as part of "minimal". And my answer definitely differs from that of a number of people :)
True. Okay, so, minimal + the minimum X required to install firstboot with a package chooser. With an option to do *just* minimal for experts. :)
There are also other problems in that CD installs become extremely annoying as you have to keep switching CDs longer. Anyway, we've been down this road of discussion before and it's just not something that makes sense to me right now and so it's not going to be done ;-)
Jeremy
On Sat, Nov 26, 2005 at 11:02:59AM -0500, Jeremy Katz wrote:
True. Okay, so, minimal + the minimum X required to install firstboot with a package chooser. With an option to do *just* minimal for experts. :)
There are also other problems in that CD installs become extremely annoying as you have to keep switching CDs longer. Anyway, we've been
Bah, CDs. :)
down this road of discussion before and it's just not something that makes sense to me right now and so it's not going to be done ;-)
I know. I just have to bring it up every now and then. :)
On 11/26/2005 09:39:49 AM, Matthew Miller wrote:
On Sat, Nov 26, 2005 at 12:50:26AM -0500, Jeremy Katz wrote:
In a lot of cases, packages which aren't listed in the comps file at all (or aren't a dependency of something) perhaps _should_ move to Extras. In addition, I think there probably are packages which should move somewhere into the comps file. File bugs against comps for things that should be listed and aren't.
How about making Anaconda always only do a minimal install, and make firstboot have the option to install other things if you want 'em? :)
That's not really a solution, because it only moves the problem to a different place. We still need to code to make selecting what a user wants to have installed easy and ergonomically sound. And if we have that code, I prefer to have it run from anaconda, because I believe that makes for the better user experience.
Regards, Willem Riede.
On Sat, Nov 26, 2005 at 09:39:49AM -0500, Matthew Miller wrote:
How about making Anaconda always only do a minimal install, and make firstboot have the option to install other things if you want 'em? :)
That's what I do with kickstart. I install the bare minimum plus cfengine (and host keys of all sorts... an interesting exercise that maybe anaconda could tackle once for all). When the system reboots, cfengine does its regular job of asking yum to install the packages defined for that machine's profile(s), tweaking configuration files, copying files from the master, (re)starting services, monitoring mounts and processes, etc.
Now, why cfengine appeared in Core (Rawhide) only for a brief period... when, as Seth pointed out, the much larger JOnAS was brought in without batting an eye. I'd argue that having cfengine in Core is a good idea. It can perform useful work at install time - without resorting to large kickstart scripts, which, by definition, are an one-off affair (you need to rely on something else to make changes after the installation). Having a bit of integration between cfengine and yum/anaconda would be even better - unless there are even more suitable alternatives.
On Sun, 2005-11-27 at 17:44 +0100, Rudi Chiarito wrote:
Now, why cfengine appeared in Core (Rawhide) only for a brief period... when, as Seth pointed out, the much larger JOnAS was brought in without batting an eye. I'd argue that having cfengine in Core is a good idea. It can perform useful work at install time - without resorting to large kickstart scripts, which, by definition, are an one-off affair (you need to rely on something else to make changes after the installation). Having a bit of integration between cfengine and yum/anaconda would be even better - unless there are even more suitable alternatives.
When Anaconda can look at more repos than just Extras (think FC6) wouldn't it make more sense to have your own yum repo with group definitions for each system profile? Then you can tell anaconda's yum to group-install <foo>. After the install, yum update will do the updating work.
On Sun, Nov 27, 2005 at 08:55:42AM -0800, Jesse Keating wrote:
When Anaconda can look at more repos than just Extras (think FC6) wouldn't it make more sense to have your own yum repo with group definitions for each system profile? Then you can tell anaconda's yum to group-install <foo>. After the install, yum update will do the updating work.
I already maintain a local yum repository.
The nice thing about cfengine is that it defines a lot of classes. When running on x86_64 it will define 64_bit rather than 32_bit, for FC4 systems it will define fedora and fedora_4, plus other classes whose names are derived from the IPv4/v6 address and subnet, running kernel version, etc. You can define your own classes, too (e.g. kickstart_server for your kickstart servers).
You can then apply actions including or excluding any number classes, using boolean and/or/not/grouping operators. I use that to build a list of packages that derives from all the classes the system belongs to.
You could use cfengine to pass a number of group names to be used for yum's groupinstall/update, but then you need to enforce that the addition of a new group happens in the yum repository first. Plus, keeping information in yet another place is inconvenient if, like me, you keep the cfengine configuration files under revision control (you'd probably want cfengine to generate the yumgroups.xml file for you in that case).
If packages are all you want to manage then, yes, yum groups are viable and cfengine is overkill - just generating and distributing the cryptographic keys is too much effort for such a small return.
Especially if you have a large number of systems, though, you'll want to go for something like cfengine and even do as much as possible with it. I use it to tweak ldap.conf/nsswitch.conf/system-auth, install PPD files and printers for CUPS, set up the NTP servers and clients, replicate files, add/mount NFS shares in fstab, turn on init.d services, set up NAT on cluster masters, manage virtual IPs, etc. This has helped cut down on the number of permutations of kickstart files I keep. At some point I realised that Anaconda's kickstart mechanism is never going to cover all your needs and huge post-install sections were not the solution (plus I needed something to automate changes that come up after the system has been installed).
BTW, cfengine is being rewritten for version 3. I also come across puppet, which looks promising: http://reductivelabs.com/projects/puppet
Matthew Miller writes:
On Sat, Nov 26, 2005 at 12:50:26AM -0500, Jeremy Katz wrote:
In a lot of cases, packages which aren't listed in the comps file at all (or aren't a dependency of something) perhaps _should_ move to Extras. In addition, I think there probably are packages which should move somewhere into the comps file. File bugs against comps for things that should be listed and aren't.
How about making Anaconda always only do a minimal install, and make firstboot have the option to install other things if you want 'em? :)
Have you forgotten firsboot is inaccessible? You do care about that, right?
-- Matthew Miller mattdm@mattdm.org http://mattdm.org/ Boston University Linux ------> http://linux.bu.edu/
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Tue, Nov 29, 2005 at 08:02:52AM -0500, Janina Sajka wrote:
How about making Anaconda always only do a minimal install, and make firstboot have the option to install other things if you want 'em? :)
Have you forgotten firsboot is inaccessible? You do care about that, right?
I *do* care about that. Firstboot should be available in text-only mode for use with screenreaders.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=66731
On Tue, 2005-11-29 at 08:14 -0500, Matthew Miller wrote:
I *do* care about that. Firstboot should be available in text-only mode for use with screenreaders.
Add enhancements to init's .unconfigured methodology. This is why I usually complain about -gui config tools being created w/out -tui counterparts.
On Tue, 2005-11-29 at 08:02 -0500, Janina Sajka wrote:
Matthew Miller writes:
On Sat, Nov 26, 2005 at 12:50:26AM -0500, Jeremy Katz wrote:
In a lot of cases, packages which aren't listed in the comps file at all (or aren't a dependency of something) perhaps _should_ move to Extras. In addition, I think there probably are packages which should move somewhere into the comps file. File bugs against comps for things that should be listed and aren't.
How about making Anaconda always only do a minimal install, and make firstboot have the option to install other things if you want 'em? :)
Have you forgotten firsboot is inaccessible? You do care about that, right?
Then let's work towards making firstboot accessible. Frankly, that should be done anyway. If you could file specific bugs about things which would help, then we can look into them and work on prioritizing them.
We'll want to make sure to take advantage of the basics of ATK at least for testing with dogtail anyway :)
Jeremy