----- "Robert P. J. Day" rpjday@crashcourse.ca wrote:
first attempt at installing f13 alpha and i'm a bit puzzled by the installation options. if i don't want the default, i can choose *one* of:
- Graphical Desktop
- Software Development
- Web Server
... etc ...
that just seems weird. so if i want both of those first two choices, i need to customize now and go in and manually select? that seems counter-productive.
It could be a list of checkboxes, instead of comboboxes. With the exception that at least one checkbox must be activated and activating "Minimal install" de-activates all other checkboxes. For some people it could be handy to select Graphical Desktop, Software Development and Web server all at once.
On the other hand, it is really easy to click "Customize now" and select the appropriate checkboxes with even a more detail. It takes just a slightly more time.
Overall it's an interesting suggestion, you can create a bugzilla [1] entry against "anaconda" package and propose that to anaconda developers.
Thanks, Kamil
On Mon, 15 Mar 2010, Kamil Paral wrote:
----- "Robert P. J. Day" rpjday@crashcourse.ca wrote:
first attempt at installing f13 alpha and i'm a bit puzzled by the installation options. if i don't want the default, i can choose *one* of:
- Graphical Desktop
- Software Development
- Web Server
... etc ...
that just seems weird. so if i want both of those first two choices, i need to customize now and go in and manually select? that seems counter-productive.
It could be a list of checkboxes, instead of comboboxes.
that's sort of what i was thinking. my memory fails me -- what did it *used* to look like? i'm pretty sure they weren't radio boxes before.
On the other hand, it is really easy to click "Customize now" and select the appropriate checkboxes with even a more detail. It takes just a slightly more time.
true, but it still requires a little more tech savvy that seems unnecessary. so, if i might ask (again?), was there a specific reason for using radio boxes in this context? perhaps there was and i just haven't seen it. i'm willing to be persuaded that this is the correct thing to do, i just haven't seen a compelling argument yet.
rday --
======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ========================================================================
----- "Robert P. J. Day" rpjday@crashcourse.ca wrote:
true, but it still requires a little more tech savvy that seems unnecessary. so, if i might ask (again?), was there a specific reason for using radio boxes in this context? perhaps there was and i just haven't seen it. i'm willing to be persuaded that this is the correct thing to do, i just haven't seen a compelling argument yet.
Try it here: https://fedoraproject.org/wiki/Anaconda#Mailing_Lists
On Mon, 15 Mar 2010, Kamil Paral wrote:
----- "Robert P. J. Day" rpjday@crashcourse.ca wrote:
true, but it still requires a little more tech savvy that seems unnecessary. so, if i might ask (again?), was there a specific reason for using radio boxes in this context? perhaps there was and i just haven't seen it. i'm willing to be persuaded that this is the correct thing to do, i just haven't seen a compelling argument yet.
Try it here: https://fedoraproject.org/wiki/Anaconda#Mailing_Lists
i'm not going to make a big deal out of this. i certainly have no problem with this since i've done more than my share of installs. i was just suggesting that if the goal was to make fedora friendlier to more newbie-type folks, that installation step seemed to be going in the wrong direction. and on that note, i'll just let it go and move on.
rday --
======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ========================================================================
On Mon, 15 Mar 2010 06:51:21 -0400 (EDT) Kamil Paral wrote:
Overall it's an interesting suggestion, you can create a bugzilla [1] entry against "anaconda" package and propose that to anaconda developers.
Yea, but we are still waiting for the "Select every optional package in all package groups" button they promised us to replace the "everything" button (unless they actually have that in f13? :-).
On 3/15/2010 7:14 AM, Tom Horsley wrote:
On Mon, 15 Mar 2010 06:51:21 -0400 (EDT) Kamil Paral wrote:
Overall it's an interesting suggestion, you can create a bugzilla [1] entry against "anaconda" package and propose that to anaconda developers.
Yea, but we are still waiting for the "Select every optional package in all package groups" button they promised us to replace the "everything" button (unless they actually have that in f13? :-).
A show of hands? How many users does 'we' represent here? :-)
Overall it's an interesting suggestion, you can
create a bugzilla [1]
entry against "anaconda" package and propose that
to anaconda
developers.
Yea, but we are still waiting for the "Select every
optional package
in all package groups" button they promised us to
replace the
"everything" button (unless they actually have that in
f13? :-).
A show of hands? How many users does 'we' represent here? :-)
--
+1) I want to be in the "we" category. I do miss that powerful click to install everything :(, while I don't install everyhing anymore I can live with it, but to go and hunt down packages *that are not in the default* installation is a pain in the A....
Regards,
Antonio
On Mon, 15 Mar 2010, Antonio Olivares wrote:
Overall it's an interesting suggestion, you can
create a bugzilla [1]
entry against "anaconda" package and propose that
to anaconda
developers.
Yea, but we are still waiting for the "Select every
optional package
in all package groups" button they promised us to
replace the
"everything" button (unless they actually have that in
f13? :-).
A show of hands? How many users does 'we' represent here? :-)
--
+1) I want to be in the "we" category. I do miss that powerful click to install everything :(, while I don't install everyhing anymore I can live with it, but to go and hunt down packages *that are not in the default* installation is a pain in the A....
i'm not sure that i'd deliberately install everything given the opportunity, but i have to think that a choice like that would be a terrific stress test for the installation process -- perhaps a hidden choice that says, "activate every possible fedora repository and grab *everything*."
i'm sure the installation team must have a secret setting like that. :-)
rday --
======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ========================================================================
On Mon, Mar 15, 2010 at 11:25:34 -0400, "Robert P. J. Day" rpjday@crashcourse.ca wrote:
i'm not sure that i'd deliberately install everything given the opportunity, but i have to think that a choice like that would be a terrific stress test for the installation process -- perhaps a hidden choice that says, "activate every possible fedora repository and grab *everything*."
I think the desire was mostly for installing everything on the install media, not everything available for Fedora.
I think that is a reasonable idea and used to have some interest in it, but I don't do installs that way any more so it's not something I personally care much about any more. Installing from a live image (which I do do) is pretty much the same thing as you get everything on the live image.
On Mon, Mar 15, 2010 at 3:34 PM, Bruno Wolff III bruno@wolff.to wrote:
On Mon, Mar 15, 2010 at 11:25:34 -0400, "Robert P. J. Day" rpjday@crashcourse.ca wrote:
i'm not sure that i'd deliberately install everything given the opportunity, but i have to think that a choice like that would be a terrific stress test for the installation process -- perhaps a hidden choice that says, "activate every possible fedora repository and grab *everything*."
I think the desire was mostly for installing everything on the install media, not everything available for Fedora.
I think that is a reasonable idea and used to have some interest in it, but I don't do installs that way any more so it's not something I personally care much about any more. Installing from a live image (which I do do) is pretty much the same thing as you get everything on the live image.
I must admit I carefully go through the package lists on every install - but I also build my own install isos and the one thing that I have never fathomed out is how to alter the comps list so that the default package manifest is altered to my own taste - I can certainly add available packages to the install and select them but it would be oh so nice to be able to build an install iso (mainly for installing after lots of new updates are in some weeks or months after a release) that has my choice of default packages.
If anyone can point me to a guide on this specific issue I would appreciate it. (I use mock/pungi to create iso builds)
On Mon, 15 Mar 2010, mike cloaked wrote:
I must admit I carefully go through the package lists on every install - but I also build my own install isos and the one thing that I have never fathomed out is how to alter the comps list so that the default package manifest is altered to my own taste - I can certainly add available packages to the install and select them but it would be oh so nice to be able to build an install iso (mainly for installing after lots of new updates are in some weeks or months after a release) that has my choice of default packages.
If anyone can point me to a guide on this specific issue I would appreciate it. (I use mock/pungi to create iso builds)
if you figure out the recipe, could you post it or link to it for the benefit of the rest of us?
rday --
======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ========================================================================
On Mon, Mar 15, 2010 at 5:59 PM, Robert P. J. Day rpjday@crashcourse.ca wrote:
On Mon, 15 Mar 2010, mike cloaked wrote:
I must admit I carefully go through the package lists on every install - but I also build my own install isos and the one thing that I have never fathomed out is how to alter the comps list so that the default package manifest is altered to my own taste - I can certainly add available packages to the install and select them but it would be oh so nice to be able to build an install iso (mainly for installing after lots of new updates are in some weeks or months after a release) that has my choice of default packages.
If anyone can point me to a guide on this specific issue I would appreciate it. (I use mock/pungi to create iso builds)
if you figure out the recipe, could you post it or link to it for the benefit of the rest of us?
I presume that you mean for changing comps? If so then sure -
On Mon, 2010-03-15 at 11:25 -0400, Robert P. J. Day wrote:
i'm sure the installation team must have a secret setting like that. :-)
%packages * %end
On 3/15/2010 11:19 AM, Antonio Olivares wrote:
Overall it's an interesting suggestion, you can
create a bugzilla [1]
entry against "anaconda" package and propose that
to anaconda
developers.
Yea, but we are still waiting for the "Select every
optional package
in all package groups" button they promised us to
replace the
"everything" button (unless they actually have that in
f13? :-).
A show of hands? How many users does 'we' represent here? :-)
--
+1) I want to be in the "we" category. I do miss that powerful click to install everything :(, while I don't install everyhing anymore I can live with it, but to go and hunt down packages *that are not in the default* installation is a pain in the A....
Are the number of packages that you hunt down and add included in the 'everything' packages selection?
How many packages would this 'everything' install that you do *not* want?
These 'everything' packages are also potential updates from time to time. Do you want to keep 'everything' packages that you don't want updated too?
This thinking has never made sense to me.
but to go and hunt down packages *that are not in the default* installation is a pain in the A....
<usual rant> for me, there is much more pain to hunt down the packages that I don't need/want and that *are* in the default install (even after unchecking everything possible) </usual rant>
K.
On Tue, 16 Mar 2010 10:40:06 +0100 Karel Volný wrote:
for me, there is much more pain to hunt down the packages that I don't need/want and that *are* in the default install (even after unchecking everything possible)
Especially when I do things like explicitly uncheck "Fedora Eclipse" and it installs eclipse anyway :-).
On 3/16/2010 5:50 AM, Tom Horsley wrote:
On Tue, 16 Mar 2010 10:40:06 +0100 Karel Volný wrote:
for me, there is much more pain to hunt down the packages that I don't need/want and that *are* in the default install (even after unchecking everything possible)
Especially when I do things like explicitly uncheck "Fedora Eclipse" and it installs eclipse anyway :-).
Come on now Tom. You know how this works. 'Package Something' that you *do* install requires Eclipse so Eclipse gets pulled in as a dependancy or that 'Package Something' would not work.
On Tue, 16 Mar 2010 13:52:09 -0400 David wrote:
Come on now Tom. You know how this works. 'Package Something' that you *do* install requires Eclipse so Eclipse gets pulled in as a dependancy or that 'Package Something' would not work.
You'd think that, but later when I do
yum erase eclipse
the only dependencies it removes are other things with eclipse in the name. I would have hoped that all the things with eclipse in the name were included in the group named "Fedora Eclispe" :-).
On 3/16/2010 2:04 PM, Tom Horsley wrote:
On Tue, 16 Mar 2010 13:52:09 -0400 David wrote:
Come on now Tom. You know how this works. 'Package Something' that you *do* install requires Eclipse so Eclipse gets pulled in as a dependancy or that 'Package Something' would not work.
You'd think that, but later when I do
yum erase eclipse
the only dependencies it removes are other things with eclipse in the name. I would have hoped that all the things with eclipse in the name were included in the group named "Fedora Eclispe" :-).
Well... :-) that is odd then.
for me, there is much more pain to hunt down the
packages that I
don't need/want and that *are* in the default
install (even after
unchecking everything possible)
Especially when I do things like explicitly uncheck
"Fedora Eclipse"
and it installs eclipse anyway :-).
Come on now Tom. You know how this works. 'Package Something' that you *do* install requires Eclipse so Eclipse gets pulled in as a dependancy or that 'Package Something' would not work.
--
Sad but very TRUE :) That is the way the ball bounces!
Regards,
Antonio
On 3/16/2010 2:13 PM, Antonio Olivares wrote:
packages that I install (even after "Fedora Eclipse"
Come on now Tom. You know how this works. 'Package Something' that you *do* install requires Eclipse so Eclipse gets pulled in as a dependancy or that 'Package Something' would not work.
--
Sad but very TRUE :) That is the way the ball bounces!
I was of the impression that it, Linux, was designed that way. Why put the same files in many different packages. It would make them much larger.
There are many 'things' that you can not deselect. System language support. System Fonts. Xorg drivers. Even Firefox and Thunderbird will install support for every language available. For a good reason of course.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 15 Mar 2010, Tom Horsley wrote:
On Mon, 15 Mar 2010 06:51:21 -0400 (EDT) Kamil Paral wrote:
Overall it's an interesting suggestion, you can create a bugzilla [1] entry against "anaconda" package and propose that to anaconda developers.
Yea, but we are still waiting for the "Select every optional package in all package groups" button they promised us to replace the "everything" button (unless they actually have that in f13? :-).
I'm pretty sure we [anaconda] never made that promise.
The names of the tasks maybe need more description. The reason they are radio buttons instead of checkboxes is that the choices indicate preset lists of yum package groups to install. You can select a task and all of the default packages (as defined in comps) for the groups in that task will get installed, as well as any package dependencies. As of now, this is what the task definition looks like for Fedora:
Graphical Desktop admin-tools base base-x core editors fonts games gnome-desktop graphical-internet graphics hardware-support input-methods java office printing sound-and-video text-internet
Software Development base base-x core development-libs development-tools editors fonts gnome-desktop gnome-software-development graphical-internet graphics hardware-support input-methods java text-internet x-software-development
Web Server admin-tools base base-x core editors gnome-desktop graphical-internet hardware-support java text-internet web-server
Minimal core
These are the same group names that can be used in the %packages section of a kickstart file, in @groupname syntax.
We can modify these tasks, change the names, or add new ones. File bugs against anaconda accordingly.
Keep in mind that the idea behind these tasks is to greatly simplify the job of selecting software for installation. They are intended to hit the most common use cases and avoid the need for users to get in to a detailed package selection mode. Users wanting finegrained control over what packages get installed already have that. You can already customize the package list or build a kickstart file to your liking.
- -- David Cantrell dcantrell@redhat.com Red Hat / Honolulu, HI
On Mon, 2010-03-15 at 09:50 -1000, David Cantrell wrote:
The names of the tasks maybe need more description. The reason they are radio buttons instead of checkboxes is that the choices indicate preset lists of yum package groups to install.
I may be dim, but why does that mean they have to be radio buttons? Can't anaconda just sum the list of package groups if you pick more than one option? I don't see any intrinsic reason why the user _shouldn't_ be allowed to configure a system that's both a Graphical Desktop and a Software Development system, say.
On Mon, 15 Mar 2010, Adam Williamson wrote:
On Mon, 2010-03-15 at 09:50 -1000, David Cantrell wrote:
The names of the tasks maybe need more description. The reason they are radio buttons instead of checkboxes is that the choices indicate preset lists of yum package groups to install.
I may be dim, but why does that mean they have to be radio buttons? Can't anaconda just sum the list of package groups if you pick more than one option? I don't see any intrinsic reason why the user _shouldn't_ be allowed to configure a system that's both a Graphical Desktop and a Software Development system, say.
i was about to make precisely the same observation -- i don't know a single person amongst my linux social circle that would install a system that didn't incorporate the graphical desktop *and* the standard S/W development tools.
and, yes, i *realize* that one can always pop into customization to set it up exactly the way you want, but the whole point of those initial radio boxes is, i assume, to give people a quick way to pick a configuration, but that doesn't do much good if the only configurations you support are combinations that most people wouldn't select in the first place.
i suppose one could put in a BZ request but i can't imagine that would have much effect since that really would constitute a major change in functionality.
rday --
======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ========================================================================
On Mon, Mar 15, 2010 at 4:04 PM, Robert P. J. Day rpjday@crashcourse.ca wrote:
i was about to make precisely the same observation -- i don't know a single person amongst my linux social circle that would install a system that didn't incorporate the graphical desktop *and* the standard S/W development tools.
The software development tools is a particular pain point: I've found it easier to reinstall a system that missed that option rather than endure a never-ending battle with missing packages. "No C compiler?! wtf? Okay. Gcc installed. ... C++ doesn't work? argh!"
I can see leaving out the development tools from an embedded / super-slim install... But there are a lot of GNU/Linux applications and instructions that expects the basic toolchains to just be there. In our quest to make Fedora as easy and friendly as OSX and Windows, we must take care to not abandon the parts that make it _better_. Easy access to source and development tools are a powerful advantage, even for those whom the benefit is mostly theoretical.
On Mon, Mar 15, 2010 at 17:13:14 -0400, Gregory Maxwell gmaxwell@gmail.com wrote:
The software development tools is a particular pain point: I've found it easier to reinstall a system that missed that option rather than endure a never-ending battle with missing packages. "No C compiler?! wtf? Okay. Gcc installed. ... C++ doesn't work? argh!"
Groups might be a help here. For example in the above case, yum groupinstall "Development Tools" might solve most of the problem.
On Mon, 2010-03-15 at 16:24 -0500, Bruno Wolff III wrote:
Groups might be a help here. For example in the above case, yum groupinstall "Development Tools" might solve most of the problem.
Indeed. It would be nice if such groups were discoverable e.g. in gpk-application. Right now, there's a collection called "Programming" and a filter called "Development" and it's unclear how these related to the yum group.
-B.
On Mon, 2010-03-15 at 20:29 -0400, Christopher Beland wrote:
On Mon, 2010-03-15 at 16:24 -0500, Bruno Wolff III wrote:
Groups might be a help here. For example in the above case, yum groupinstall "Development Tools" might solve most of the problem.
Indeed. It would be nice if such groups were discoverable e.g. in gpk-application. Right now, there's a collection called "Programming" and a filter called "Development" and it's unclear how these related to the yum group.
Click on 'Package collections', wait, then expand 'Development'
On Mon, Mar 15, 2010 at 20:29:12 -0400, Christopher Beland beland@alum.mit.edu wrote:
On Mon, 2010-03-15 at 16:24 -0500, Bruno Wolff III wrote:
Groups might be a help here. For example in the above case, yum groupinstall "Development Tools" might solve most of the problem.
Indeed. It would be nice if such groups were discoverable e.g. in gpk-application. Right now, there's a collection called "Programming" and a filter called "Development" and it's unclear how these related to the yum group.
There are two types of groupings that you might run into. One is comps which is what yum uses for groups. Another is in the rpm data. I don't know how the two group mechanisms are supposed to relate or even if they are.
You can use yum to get a list of comps groups. yum grouplist
You can list the contents of a comps group with yum groupinfo "Group name of interest"
Robert P. J. Day (rpjday@crashcourse.ca) said:
i was about to make precisely the same observation -- i don't know a single person amongst my linux social circle that would install a system that didn't incorporate the graphical desktop *and* the standard S/W development tools.
If you'll re-read the list of tasks he posted, the development task includes the desktop.
Bill
On 03/16/2010 10:55 AM, Bill Nottingham wrote:
Robert P. J. Day (rpjday@crashcourse.ca) said:
i was about to make precisely the same observation -- i don't know a single person amongst my linux social circle that would install a system that didn't incorporate the graphical desktop *and* the standard S/W development tools.
If you'll re-read the list of tasks he posted, the development task includes the desktop.
But does not include printing. I guess software developers aren't supposed to print anything these days.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 16 Mar 2010, Robert Nichols wrote:
On 03/16/2010 10:55 AM, Bill Nottingham wrote:
Robert P. J. Day (rpjday@crashcourse.ca) said:
i was about to make precisely the same observation -- i don't know a single person amongst my linux social circle that would install a system that didn't incorporate the graphical desktop *and* the standard S/W development tools.
If you'll re-read the list of tasks he posted, the development task includes the desktop.
But does not include printing. I guess software developers aren't supposed to print anything these days.
This is an example of where the task can be expanded, to which I said file bugs against anaconda as needed.
- -- David Cantrell dcantrell@redhat.com Red Hat / Honolulu, HI
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 15 Mar 2010, Adam Williamson wrote:
On Mon, 2010-03-15 at 09:50 -1000, David Cantrell wrote:
The names of the tasks maybe need more description. The reason they are radio buttons instead of checkboxes is that the choices indicate preset lists of yum package groups to install.
I may be dim, but why does that mean they have to be radio buttons? Can't anaconda just sum the list of package groups if you pick more than one option? I don't see any intrinsic reason why the user _shouldn't_ be allowed to configure a system that's both a Graphical Desktop and a Software Development system, say.
That's just the way we implemented it. The driving force behind these decisions was to make things simple for the user. When presented with check boxes at this point, we found most users would either (a) leave the default choices in place and continue or (b) check them all for fear of missing something.
If you remember older releases of Red Hat Linux, you could select Workstation, Server, or some such list of system types. That was basically the same idea for package selection.
That said, I'm not trying to defend the radio buttons, just explain what they are and how they work. Check boxes make perfect sense, but before just changing them over, I would first say we should really look at the tasks as defined now and see if they should be changed, expanded, or reduced.
- -- David Cantrell dcantrell@redhat.com Red Hat / Honolulu, HI
On 03/15/2010 04:38 PM, David Cantrell wrote:
That's just the way we implemented it. The driving force behind these decisions was to make things simple for the user. When presented with check boxes at this point, we found most users would either (a) leave the default choices in place and continue or (b) check them all for fear of missing something.
Please dont confuse simpler with limited funtionality.
Focus on what makes users lives easier to admin/install these systems - rather than putting artificial hurdles in place for questionable rationale.
If some choose all packages groups (b) - why do you even care? The majority who make those choices may well know exactly what they need.
gene
David Cantrell (dcantrell@redhat.com) said:
That's just the way we implemented it. The driving force behind these decisions was to make things simple for the user. When presented with check boxes at this point, we found most users would either (a) leave the default choices in place and continue or (b) check them all for fear of missing something.
Also, by having the the tasks be explicit lists of groups, as opposed to sets of groups that can be combined on top of some nebulous 'common' set of groups, you:
- don't have to have weirdness with where you specify that common set of groups - can define a minimal install sanely in the same context
Bill
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 16 Mar 2010, Bill Nottingham wrote:
David Cantrell (dcantrell@redhat.com) said:
That's just the way we implemented it. The driving force behind these decisions was to make things simple for the user. When presented with check boxes at this point, we found most users would either (a) leave the default choices in place and continue or (b) check them all for fear of missing something.
Also, by having the the tasks be explicit lists of groups, as opposed to sets of groups that can be combined on top of some nebulous 'common' set of groups, you:
- don't have to have weirdness with where you specify that common set of
groups
- can define a minimal install sanely in the same context
Very true. In keeping with the spirit of minimizing installer complexity, we purposely chose not to implement various forms of choose-your-own-adventure package selection. You can customize package selection now, which is more than I think we really need in the installer, but I could be alone on that one. I think the tasks we present users in the interactive installer are plenty for package selection for several reasons:
1) Advanced users all have different ideas of the perfect package selection interface and they never really align -or- if they do, no one ever uses them because "that's not what an advanced user would do". For advanced users, I think we already have two perfectly acceptable solutions: a) make your own spin b) create a kickstart file
2) Once yum entered the distribution a long time ago, I always wondered what all the fuss over package selection in the installer was about. Didn't get something during installation? Add it with yum. Done. Why is that hard?
3) For the non-network connected users who absolutely need to have all packages or specific sets of packages installed by anaconda, choices 1a and 1b work just fine. Some may say that's a lot of work, but you're using a system not on a network, so you're really not doing things the easy way to begin with. Also, you can always prepare a system by running through the installer, then using yum to add/remove things, then use the output of:
rpm -qa --queryformat "%{name}\n" | sort | uniq
For the %packages section in a kickstart file.
So, if you have suggestions for the task definitions in the installer, or ideas for new tasks, let us know.
- -- David Cantrell dcantrell@redhat.com Red Hat / Honolulu, HI
On Tue, Mar 16, 2010 at 1:00 PM, David Cantrell dcantrell@redhat.com wrote:
- Advanced users all have different ideas of the perfect package selection
interface and they never really align -or- if they do, no one ever uses them because "that's not what an advanced user would do". For advanced users, I think we already have two perfectly acceptable solutions: a) make your own spin b) create a kickstart file
I think this is an example of a re-occurring pattern in Fedora decision making which I consider to be misguided.
A sufficiently advanced user _could_ make their own spin, they could make their own kickstart file. But these things are very large resource investments, not just once but again each fedora revision to track the changes in behaviour.
The same sufficiently advanced user could forgo fedora or any other distribution entirely and build up their GNU/Linux system from source tarballs. Advanced users use fedora because making your own distribution is an enormous resource expenditure, and we're willing to tolerate some decisions we wouldn't have personally made in order to avoid expending those resources.
Every single customization I make to my fedora system reduces the benefit that Fedora provides. It wastes my time now, and it wastes it once to several times per year as Fedora updates and releases come out which break my non-standard configuration.
At least for me, I tolerate things that I think which suck about fedora in many cases rather than customizing because at least the harm is bound— If I customize there is no telling how deep the rabbit hole goes.
I can accept that providing more choices has a cost, especially to inexperienced users. But failing to provide importance choices also has a cost. It's valid to weigh these costs, but not valid to take the cost to advanced users as zero simply because of their crime of experience.
When both are weighed a reasonable compromise can be found... things like a zero option install, with an advanced tab hiding a nice array of buttons. Inexperienced users are saved confusion, advanced users don't have to become fedora build system experts twice a year.
Obviously Fedora can not satisfy every possible mutually exclusive advanced configuration, and Fedora ought not adopt an advanced-user friendly behaviour which is actively harmful to less sophisticated users. But I see many cases of "oh, advanced users can customize" being bandied about in cases where no such conflict exists, used as the justification for removing and hiding features and changing defaults in ways that give no benefit to the common user, and I think that practice is bogus.
More than that, it's a regression. F12 and previous allows the selection of Graphical Desktop, Web Server and Software Development.
That new Minimal option is really interesting however. I'd like to see that used as the base install on customer servers where I work now.
On Wed, 17 Mar 2010, Chris Kloiber wrote:
More than that, it's a regression. F12 and previous allows the selection of Graphical Desktop, Web Server and Software Development.
i thought as much but i hadn't installed for a while so i couldn't be sure. this new selection strategy strikes me as a hideously bad choice. as i mentioned earlier, most people i know want *both* the graphical desktop and all the dev stuff. now we can't quickly select that and we have to jump into "customize now." bad, bad idea.
rday --
======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ========================================================================
I used to work at Red Hat. I remember the heated discussion over the removal of the "Everything" install. I used to use it all the time as I worked in Global Support Services and liked having "Everything" installed on my desktop. Jeremy Katz basically just said "no" and that was the end of it as I recall. No promise to put it back. That was over 5 years ago now, but I doubt that's changed.
On Wed, 2010-03-17 at 04:38 -0400, Chris Kloiber wrote:
I used to work at Red Hat. I remember the heated discussion over the removal of the "Everything" install. I used to use it all the time as I worked in Global Support Services and liked having "Everything" installed on my desktop. Jeremy Katz basically just said "no" and that was the end of it as I recall. No promise to put it back. That was over 5 years ago now, but I doubt that's changed.
It was more than just "no". It was decided to be removed due to all the bugs we were getting because people had different ideas as to what "everything" actually meant. Some felt "everything" meant all packages possible. Some felt "everything" meant all packages excluding all the language packages for unselected languages. Some felt "everything" meant all possible multilib packages, some felt it didn't. Clearly we weren't going to satisfy everybody with an 'Everything' option so it was removed so that folks can pick their own vision of "Everything".
On Wed, 17 Mar 2010 08:50:36 -0700 Jesse Keating wrote:
Clearly we weren't going to satisfy everybody with an 'Everything' option so it was removed so that folks can pick their own vision of "Everything".
Which means the problem was with the label of the 'Everything' button, not the concept of a button to simply and easily select lots of stuff. Which was why I wanted the button renamed to:
'Select all optional packages in all package groups'
No longer ambiguous, and I can even do it now with scads of mouse clicks, it would just be simpler to do with one click. I'm much rather do that, then winnow out the stuff I know for a fact I don't want (there is much less of that :-).
On Wed, 2010-03-17 at 12:47 -0400, Tom Horsley wrote:
On Wed, 17 Mar 2010 08:50:36 -0700 Jesse Keating wrote:
Clearly we weren't going to satisfy everybody with an 'Everything' option so it was removed so that folks can pick their own vision of "Everything".
Which means the problem was with the label of the 'Everything' button, not the concept of a button to simply and easily select lots of stuff. Which was why I wanted the button renamed to:
'Select all optional packages in all package groups'
No longer ambiguous, and I can even do it now with scads of mouse clicks, it would just be simpler to do with one click. I'm much rather do that, then winnow out the stuff I know for a fact I don't want (there is much less of that :-).
There is not room for all the buttons everyone wants.
Also, your desired case is still ambiguous. Both exim and postfix are optional in @mail-server. Which one should win? (This is rhetorical. Do not answer it.)
- ajax
On Wed, 17 Mar 2010 13:09:40 -0400 Adam Jackson wrote:
Also, your desired case is still ambiguous.
No, it is not ambiguous. Today, I can right click on every package group and say "select all optional packages". Whatever that does is exactly what this button does. No ambiguity at all, just a shorthand for something I can do anyway with a lot more work.
You could say the "select all optional packages" right click menu item is ambiguous, but you can't say the button is ambiguous :-). (And the context menu does in fact exist and does something).