Hi,
I think if possible the fedora installer can be modified to present two install option to the user :
1. Desktop Install.
2. Server Install.
Thanks.
regards,
Shambo Bose
On Thursday 09 October 2008 10:12:18 pm Shambo Bose wrote:
Hi,
I think if possible the fedora installer can be modified to present two install option to the user :
Desktop Install.
Server Install.
Thanks.
regards,
Shambo Bose
Any user who actually wants a 'Server Install' knows enough to uncheck GNOME, X, etc if they don't want them.
Conrad Meyer wrote:
On Thursday 09 October 2008 10:12:18 pm Shambo Bose wrote:
Hi,
I think if possible the fedora installer can be modified to present two install option to the user :
Desktop Install.
Server Install.
Thanks.
regards,
Shambo Bose
Any user who actually wants a 'Server Install' knows enough to uncheck GNOME, X, etc if they don't want them.
Doesn't mean its not a pain in the ass. Hell, its taken me 3 tries to install Fedora without having GNOME pulled in as a dependency before.
--CJD
On Thursday 09 October 2008 10:52:02 pm Casey Dahlin wrote:
Conrad Meyer wrote:
On Thursday 09 October 2008 10:12:18 pm Shambo Bose wrote:
Hi,
I think if possible the fedora installer can be modified to present two install option to the user :
Desktop Install.
Server Install.
Thanks.
regards,
Shambo Bose
Any user who actually wants a 'Server Install' knows enough to uncheck GNOME, X, etc if they don't want them.
Doesn't mean its not a pain in the ass. Hell, its taken me 3 tries to install Fedora without having GNOME pulled in as a dependency before.
--CJD
You can always remove it later. It's not a huge deal either way.
On Thu, 2008-10-09 at 22:59 -0700, Conrad Meyer wrote:
On Thursday 09 October 2008 10:52:02 pm Casey Dahlin wrote:
Conrad Meyer wrote:
On Thursday 09 October 2008 10:12:18 pm Shambo Bose wrote:
Hi,
I think if possible the fedora installer can be modified to present two install option to the user :
Desktop Install.
Server Install.
Thanks.
regards,
Shambo Bose
Any user who actually wants a 'Server Install' knows enough to uncheck GNOME, X, etc if they don't want them.
Doesn't mean its not a pain in the ass. Hell, its taken me 3 tries to install Fedora without having GNOME pulled in as a dependency before.
--CJD
You can always remove it later. It's not a huge deal either way.
Well, yes, convenience, usability and flexibility aren't necessarily a strength of Fedora - I regret, but to me, Fedora has developed into a single user, single seat OS.
Ralf
2008/10/10 Conrad Meyer konrad@tylerc.org
Doesn't mean its not a pain in the ass. Hell, its taken me 3 tries to install Fedora without having GNOME pulled in as a dependency before.
--CJD
You can always remove it later. It's not a huge deal either way.
Not an ideal scenario for a network install.
On Fri, 2008-10-10 at 11:20 +0100, Paul Black wrote:
2008/10/10 Conrad Meyer konrad@tylerc.org > Doesn't mean its not a pain in the ass. Hell, its taken me 3 tries to > install Fedora without having GNOME pulled in as a dependency before. > > --CJD
You can always remove it later. It's not a huge deal either way.
Not an ideal scenario for a network install.
There you would be using kickstart, and defining what you want at a very granular level...
On Fri, 2008-10-10 at 10:42 +0530, Shambo Bose wrote:
I think if possible the fedora installer can be modified to present two install option to the user :
Desktop Install.
Server Install.
Sounds like a good candidate for an install spin.
On Fri October 10 2008, Shambo Bose wrote:
I think if possible the fedora installer can be modified to present two install option to the user :
Desktop Install.
Server Install.
and
3. Minimal Install
Iirc this can be done somehow with comps, at least I now remeber a discussion about providing a "minimal install" options and iirc it was said that this could probably be done with comps. But I do not excactly know how.
Regards, Till
On Fri, 2008-10-10 at 10:42 +0530, Shambo Bose wrote:
Desktop Install.
Server Install.
Tell you what. Try to get the majority of fedora-devel contributors to agree on what should be in each of those installs. Don't forget the international community, who often need X in order to display the language they speak.
On Fri, 2008-10-10 at 09:20 -0700, Jesse Keating wrote:
On Fri, 2008-10-10 at 10:42 +0530, Shambo Bose wrote:
Desktop Install.
Server Install.
Tell you what. Try to get the majority of fedora-devel contributors to agree on what should be in each of those installs.
Provide a "minimal install" as install option, such that sysadmins can add what they want, instead of forcing them to "manually minimize the distro", as you are doing it now.
On Fri, 2008-10-10 at 23:49 +0200, Ralf Corsepius wrote:
Provide a "minimal install" as install option, such that sysadmins can add what they want, instead of forcing them to "manually minimize the distro", as you are doing it now.
Great, now get consensus on what 'minimal' should be.
On Fri, Oct 10, 2008 at 02:52:13PM -0700, Jesse Keating wrote:
On Fri, 2008-10-10 at 23:49 +0200, Ralf Corsepius wrote:
Provide a "minimal install" as install option, such that sysadmins can add what they want, instead of forcing them to "manually minimize the distro", as you are doing it now.
Great, now get consensus on what 'minimal' should be.
No need for a consensus, pick a set of comps groups with your best judgement. It would be better than nothing. Then people can argue. If you want the arguing before, post it there, and wait for feedback.
-- Pat
On Sat, 2008-10-11 at 00:08 +0200, Patrice Dumas wrote:
No need for a consensus, pick a set of comps groups with your best judgement. It would be better than nothing. Then people can argue. If you want the arguing before, post it there, and wait for feedback.
@core with optional @base. What more/less do you want?
On Fri, Oct 10, 2008 at 03:14:18PM -0700, Jesse Keating wrote:
On Sat, 2008-10-11 at 00:08 +0200, Patrice Dumas wrote:
No need for a consensus, pick a set of comps groups with your best judgement. It would be better than nothing. Then people can argue. If you want the arguing before, post it there, and wait for feedback.
@core with optional @base. What more/less do you want?
Looks good to me.
-- Pat
On Fri, Oct 10, 2008 at 03:14:18PM -0700, Jesse Keating wrote:
On Sat, 2008-10-11 at 00:08 +0200, Patrice Dumas wrote:
No need for a consensus, pick a set of comps groups with your best judgement. It would be better than nothing. Then people can argue. If you want the arguing before, post it there, and wait for feedback.
@core with optional @base. What more/less do you want?
Also system-tools as an optional group since there are some networking apps that could be of use there. But it is not that important.
-- Pat
On Fri, 2008-10-10 at 14:52 -0700, Jesse Keating wrote:
On Fri, 2008-10-10 at 23:49 +0200, Ralf Corsepius wrote:
Provide a "minimal install" as install option, such that sysadmins can add what they want, instead of forcing them to "manually minimize the distro", as you are doing it now.
Great, now get consensus on what 'minimal' should be.
shell + networking.
Approximately the set of packages required for a networked install.
Ralf
On Sat, 2008-10-11 at 00:25 +0200, Ralf Corsepius wrote:
Great, now get consensus on what 'minimal' should be.
shell + networking.
Approximately the set of packages required for a networked install.
And does that include the ability to add more later?
On Fri, 2008-10-10 at 15:31 -0700, Jesse Keating wrote:
On Sat, 2008-10-11 at 00:25 +0200, Ralf Corsepius wrote:
Great, now get consensus on what 'minimal' should be.
shell + networking.
Approximately the set of packages required for a networked install.
And does that include the ability to add more later?
Sure, yum + rpm are a requirement.
Ralf
On Sun, 2008-10-12 at 08:09 +0200, Ralf Corsepius wrote:
Sure, yum + rpm are a requirement.
And now you're dragging in python, plus the rest of yum's deps, which I've already been told by many other people (at FUDCons, IRC, mail, etc..) is not a "minimal" install. Congratulations you've just walked into a decade + argument.
On Sun, 2008-10-12 at 16:55 -0700, Jesse Keating wrote:
On Sun, 2008-10-12 at 08:09 +0200, Ralf Corsepius wrote:
Sure, yum + rpm are a requirement.
And now you're dragging in python, plus the rest of yum's deps, which I've already been told by many other people (at FUDCons, IRC, mail, etc..) is not a "minimal" install.
You are nit-picking at words.
Though a Fedora installation with yum + rpm isn't "truely minimal", it's the minimal install to keep an installation usable/maintainable.
And yes, the fact yum pulls in python is a real problem on small systems. Even worse are the system-config-* tools, most of which pull in many more packages and don't even work without X.
Congratulations you've just walked into a decade + argument.
I don't see this.
Ralf
On Mon, 2008-10-13 at 09:29 +0200, Ralf Corsepius wrote:
You are nit-picking at words.
As was everybody who ever complained about the "minimal" install option we had.
Though a Fedora installation with yum + rpm isn't "truely minimal", it's the minimal install to keep an installation usable/maintainable.
Which is useful to some, too fat for others.
And yes, the fact yum pulls in python is a real problem on small systems. Even worse are the system-config-* tools, most of which pull in many more packages and don't even work without X.
Congratulations you've just walked into a decade + argument.
I don't see this.
Probably because you haven't been on the front line, taking the bug reports, talking to users at events, trying to tweak the targets to match expectation and continually failing because there is no singular expectation.
On Mon, Oct 13, 2008 at 08:29:11AM -0700, Jesse Keating wrote:
Probably because you haven't been on the front line, taking the bug reports, talking to users at events, trying to tweak the targets to match expectation and continually failing because there is no singular expectation.
Indeed, so just come with what you prefer. With otr without python it will be better than what is now.
-- Pat
On Mon, 2008-10-13 at 18:13 +0200, Patrice Dumas wrote:
On Mon, Oct 13, 2008 at 08:29:11AM -0700, Jesse Keating wrote:
Probably because you haven't been on the front line, taking the bug reports, talking to users at events, trying to tweak the targets to match expectation and continually failing because there is no singular expectation.
Indeed, so just come with what you prefer. With otr without python it will be better than what is now.
Not sure what you mean by "otr".
When I raised a bit of objection over adding 'yum' to the @core list, the responding argument was that if you're getting so specific in your 'minimal' install, you're either doing a chroot type install or can modify a groupdata set to strip it out for your install, whereas for all the other cases it's better to have it there.
On Mon, Oct 13, 2008 at 09:40:09AM -0700, Jesse Keating wrote:
On Mon, 2008-10-13 at 18:13 +0200, Patrice Dumas wrote:
On Mon, Oct 13, 2008 at 08:29:11AM -0700, Jesse Keating wrote:
Probably because you haven't been on the front line, taking the bug reports, talking to users at events, trying to tweak the targets to match expectation and continually failing because there is no singular expectation.
Indeed, so just come with what you prefer. With otr without python it will be better than what is now.
Not sure what you mean by "otr".
'or'
When I raised a bit of objection over adding 'yum' to the @core list, the responding argument was that if you're getting so specific in your 'minimal' install, you're either doing a chroot type install or can modify a groupdata set to strip it out for your install, whereas for all the other cases it's better to have it there.
I think that these are valid arguments, in my opinion you should just decide (as the release manager in chief or something like that ;-) for others, as there will never be an agreement. I think that it would be better to have yum, but understand perfectly that other are better with rpm only.
-- Pat
On Mon, 2008-10-13 at 18:45 +0200, Patrice Dumas wrote:
I think that these are valid arguments, in my opinion you should just decide (as the release manager in chief or something like that ;-) for others, as there will never be an agreement. I think that it would be better to have yum, but understand perfectly that other are better with rpm only.
The problem was the never ending bug parade and arguments on mailing lists, trade shows, etc...
We decided the only way to win this game was to not play at all, and we let people decide their own definition of 'minimal'.
On Mon, Oct 13, 2008 at 11:08:00AM -0700, Jesse Keating wrote:
On Mon, 2008-10-13 at 18:45 +0200, Patrice Dumas wrote:
I think that these are valid arguments, in my opinion you should just decide (as the release manager in chief or something like that ;-) for others, as there will never be an agreement. I think that it would be better to have yum, but understand perfectly that other are better with rpm only.
The problem was the never ending bug parade and arguments on mailing lists, trade shows, etc...
Indeed that will happen. But does doing nothing really prevent it from happening?
We decided the only way to win this game was to not play at all, and we let people decide their own definition of 'minimal'.
The final word is up to you (and people in the release team) to choose between all theses possibilities (not very helpful, I know, but I think that there is no clear technically superior solution so you have to make your choice based on your 'expert' judgement).
-- Pat
Le lundi 13 octobre 2008 à 21:48 +0200, Patrice Dumas a écrit :
On Mon, Oct 13, 2008 at 11:08:00AM -0700, Jesse Keating wrote:
We decided the only way to win this game was to not play at all, and we let people decide their own definition of 'minimal'.
The final word is up to you (and people in the release team) to choose between all theses possibilities (not very helpful, I know, but I think that there is no clear technically superior solution so you have to make your choice based on your 'expert' judgement).
The final word is for the people who care about this minimal thing to organise themselves and propose comps modification that permit minimal installs.
As has been stated recently comps is 100% open and there are zero barriers for a group of auditors to improvr our package classification.
On Mon, Oct 13, 2008 at 10:11:05PM +0200, Nicolas Mailhot wrote:
The final word is for the people who care about this minimal thing to organise themselves and propose comps modification that permit minimal installs.
As has been stated recently comps is 100% open and there are zero barriers for a group of auditors to improvr our package classification.
I had a look recently, and I think that comps are in a good shape for minimal installs. (there is an issue with anaconda deps being draggued in but it is an orthogonal issue). However chosing @core or @core + @base is an unsolved (and unsolvable, in my opinion) issue.
-- Pat
On Mon, 2008-10-13 at 22:32 +0200, Patrice Dumas wrote:
I had a look recently, and I think that comps are in a good shape for minimal installs. (there is an issue with anaconda deps being draggued in but it is an orthogonal issue). However chosing @core or @core + @base is an unsolved (and unsolvable, in my opinion) issue.
How so? You uncheck everything to get @core, you uncheck everything but the Base group to get @core + @base
On Mon, Oct 13, 2008 at 01:45:47PM -0700, Jesse Keating wrote:
On Mon, 2008-10-13 at 22:32 +0200, Patrice Dumas wrote:
I had a look recently, and I think that comps are in a good shape for minimal installs. (there is an issue with anaconda deps being draggued in but it is an orthogonal issue). However chosing @core or @core + @base is an unsolved (and unsolvable, in my opinion) issue.
How so? You uncheck everything to get @core, you uncheck everything but the Base group to get @core + @base
It isn't what I meant, I meant it is unsolvable to tell whether minimal is @core or @code + @base.
-- Pat
On Tue, 2008-10-14 at 00:10 +0200, Patrice Dumas wrote:
On Mon, Oct 13, 2008 at 01:45:47PM -0700, Jesse Keating wrote:
On Mon, 2008-10-13 at 22:32 +0200, Patrice Dumas wrote:
I had a look recently, and I think that comps are in a good shape for minimal installs. (there is an issue with anaconda deps being draggued in but it is an orthogonal issue). However chosing @core or @core + @base is an unsolved (and unsolvable, in my opinion) issue.
How so? You uncheck everything to get @core, you uncheck everything but the Base group to get @core + @base
It isn't what I meant, I meant it is unsolvable to tell whether minimal is @core or @code + @base.
Right, because "minimal" is defined in the eye of the installer, IE the person doing the installing.
Jesse Keating wrote:
On Tue, 2008-10-14 at 00:10 +0200, Patrice Dumas wrote:
On Mon, Oct 13, 2008 at 01:45:47PM -0700, Jesse Keating wrote:
On Mon, 2008-10-13 at 22:32 +0200, Patrice Dumas wrote:
I had a look recently, and I think that comps are in a good shape for minimal installs. (there is an issue with anaconda deps being draggued in but it is an orthogonal issue). However chosing @core or @core + @base is an unsolved (and unsolvable, in my opinion) issue.
How so? You uncheck everything to get @core, you uncheck everything but the Base group to get @core + @base
It isn't what I meant, I meant it is unsolvable to tell whether minimal is @core or @code + @base.
Right, because "minimal" is defined in the eye of the installer, IE the person doing the installing.
I've spent 3 days just trying to /find/ all the crap Anaconda put on a computer that I didn't check off. Now, when I install Fedora on a server, I reboot and start over if I see anything that looks even remotely desktop-related. This is a broken use case. Solutions are:
1) Add the "dependencies have been added" screen that every other package install tool in the distro has but Anaconda insists on going without. 2) Have checkboxes in the package screen be tri-state. (checked if you want it, unchecked if you don't want it, red x if yum is not allowed to install it for any reason). This one's not pretty, but it'd work. 3) Provide a default install. Believe me, I won't agree with what you put in it at all. I will, however, be happier than I am now. 4) Document the procedure a few emails up on how to install just @core or @core + @base . I didn't even know the system would run right if you unchecked everything.
Spending a little energy and not pleasing everyone is a lot better than spending no energy and epic failing.
--CJD
On Tue, 2008-10-21 at 21:52 -0400, Casey Dahlin wrote:
I've spent 3 days just trying to /find/ all the crap Anaconda put on a computer that I didn't check off.
You spend 3 days reading the install log? Do you have reading comprehension problems? I wouldn't think so given the emails and blog posts you produce...
Now, when I install Fedora on a server, I reboot and start over if I see anything that looks even remotely desktop-related. This is a broken use case. Solutions are:
- Add the "dependencies have been added" screen that every other
package install tool in the distro has but Anaconda insists on going without.
Have you filed this RFE in bugzilla against anaconda? Unless you make this an autoclosing summary you've just broken a feature that people have been asking for for quite a while, the ability to just walk away once depsolving starts. If depsolving is successful the install should just start without any further interaction. Also, fun to figure out for kickstarts.
- Have checkboxes in the package screen be tri-state. (checked if you
want it, unchecked if you don't want it, red x if yum is not allowed to install it for any reason). This one's not pretty, but it'd work.
And just how is yum supposed to know that it can't install it? Where does that information come from, and if we have that information, why would we ever even display the package then? "Here is something you can't click! neener neener neeeeener!"
- Provide a default install.
We have one, it's what happens if you go next next next. It's defined in comps by the groups that are marked as default and the packages therein that are defined as mandatory and default. It's also what you get in kickstarts if you do %packages --default.
Believe me, I won't agree with what you put in it at all. I will, however, be happier than I am now.
Then be happy.
- Document the procedure a few emails up on how to install just @core
or @core + @base . I didn't even know the system would run right if you unchecked everything.
It all depends on your definition of "run". It'll boot. Does one really need to document the process of unchecking boxes? (or checking the Base group box)
Spending a little energy and not pleasing everyone is a lot better than spending no energy and epic failing.
You have an epic ability to blow things out of proportion. Maybe if you looked at the anaconda source, or comps, and provided patches for what you'd like to see, not only would it be helpful, but you'd also have more code to rant about in your blogs!
Jesse Keating wrote:
On Tue, 2008-10-21 at 21:52 -0400, Casey Dahlin wrote:
I've spent 3 days just trying to /find/ all the crap Anaconda put on a computer that I didn't check off.
You spend 3 days reading the install log? Do you have reading comprehension problems? I wouldn't think so given the emails and blog posts you produce...
Having been around longer and now knowing what all of that is, it takes less time these days. Do we expect everyone who just doesn't want what they didn't ask for to know what libpango does? Or do we just expect them to try each and every package in there and see which ones do and do not try to take yum with them?
Now, when I install Fedora on a server, I reboot and start over if I see anything that looks even remotely desktop-related. This is a broken use case. Solutions are:
- Add the "dependencies have been added" screen that every other
package install tool in the distro has but Anaconda insists on going without.
Have you filed this RFE in bugzilla against anaconda? Unless you make this an autoclosing summary you've just broken a feature that people have been asking for for quite a while, the ability to just walk away once depsolving starts. If depsolving is successful the install should just start without any further interaction. Also, fun to figure out for kickstarts.
You've posed a problem and a solution.
- Have checkboxes in the package screen be tri-state. (checked if you
want it, unchecked if you don't want it, red x if yum is not allowed to install it for any reason). This one's not pretty, but it'd work.
And just how is yum supposed to know that it can't install it? Where does that information come from, and if we have that information, why would we ever even display the package then? "Here is something you can't click! neener neener neeeeener!"
All reasons it isn't pretty.
- Provide a default install.
We have one, it's what happens if you go next next next. It's defined in comps by the groups that are marked as default and the packages therein that are defined as mandatory and default. It's also what you get in kickstarts if you do %packages --default.
I meant "minimal" instead of "default." Typo
Believe me, I won't agree with what you put in it at all. I will, however, be happier than I am now.
Then be happy.
- Document the procedure a few emails up on how to install just @core
or @core + @base . I didn't even know the system would run right if you unchecked everything.
It all depends on your definition of "run". It'll boot. Does one really need to document the process of unchecking boxes? (or checking the Base group box)
None of this is apparent to a user who doesn't know about Fedora. Again, the line here is not just technical and non-technical. Will the Debian administrator who is trying out Fedora think of this procedure the first time out? Likely he'll try to select all the packages he wants and end up getting a hundred things he didn't. Install nothing and add later is not the first instinct of the user.
Spending a little energy and not pleasing everyone is a lot better than spending no energy and epic failing.
You have an epic ability to blow things out of proportion. Maybe if you looked at the anaconda source, or comps, and provided patches for what you'd like to see, not only would it be helpful, but you'd also have more code to rant about in your blogs!
Oh, were those /your/ cheerios I was pissing in?
--CJD
On Thu, Oct 23, 2008 at 02:10:35AM -0400, Casey Dahlin wrote:
Having been around longer and now knowing what all of that is, it takes less time these days. Do we expect everyone who just doesn't want what they didn't ask for to know what libpango does? Or do we just expect them to try each and every package in there and see which ones do and do not try to take yum with them?
yum-protect-packages plugin will help there. :)
On Thu, 2008-10-23 at 02:10 -0400, Casey Dahlin wrote:
Having been around longer and now knowing what all of that is, it takes less time these days. Do we expect everyone who just doesn't want what they didn't ask for to know what libpango does? Or do we just expect them to try each and every package in there and see which ones do and do not try to take yum with them?
Yet you expect the comps maintainers to be able to make a decision about what every other person needs without knowing those people? That's a laugh.
Now, when I install Fedora on a server, I reboot and start over if I see anything that looks even remotely desktop-related. This is a broken use case. Solutions are:
- Add the "dependencies have been added" screen that every other
package install tool in the distro has but Anaconda insists on going without.
Have you filed this RFE in bugzilla against anaconda? Unless you make this an autoclosing summary you've just broken a feature that people have been asking for for quite a while, the ability to just walk away once depsolving starts. If depsolving is successful the install should just start without any further interaction. Also, fun to figure out for kickstarts.
You've posed a problem and a solution.
There was no solution there.
- Have checkboxes in the package screen be tri-state. (checked if you
want it, unchecked if you don't want it, red x if yum is not allowed to install it for any reason). This one's not pretty, but it'd work.
And just how is yum supposed to know that it can't install it? Where does that information come from, and if we have that information, why would we ever even display the package then? "Here is something you can't click! neener neener neeeeener!"
All reasons it isn't pretty.
You still didn't answer the question. How is yum supposed to know it's 'not allowed to install it'. Where have you ran into a situation where anaconda showed you a checkbox you were not allowed to check? I'm honestly curious why this is even being talked about.
- Provide a default install.
We have one, it's what happens if you go next next next. It's defined in comps by the groups that are marked as default and the packages therein that are defined as mandatory and default. It's also what you get in kickstarts if you do %packages --default.
I meant "minimal" instead of "default." Typo
Believe me, I won't agree with what you put in it at all. I will, however, be happier than I am now.
Then be happy.
- Document the procedure a few emails up on how to install just @core
or @core + @base . I didn't even know the system would run right if you unchecked everything.
It all depends on your definition of "run". It'll boot. Does one really need to document the process of unchecking boxes? (or checking the Base group box)
None of this is apparent to a user who doesn't know about Fedora.
Neither will the meaning of 'minimal' be. Will it have networking? Will it have yum? Will it have ssh? Will it speak my language? So on, and so forth.
Again, the line here is not just technical and non-technical. Will the Debian administrator who is trying out Fedora think of this procedure the first time out? Likely he'll try to select all the packages he wants and end up getting a hundred things he didn't. Install nothing and add later is not the first instinct of the user.
Neither is not reviewing the selection and being "surprised" when there is a lot of stuff installed. The software screen even says:
"The default installation of Fedora includes a set of software applicable for general internet usage. What additional tasks would you like your system to include support for?"
In what way does that sound like "just adding what else I need will result in a very minimal install with just what I added"?
Spending a little energy and not pleasing everyone is a lot better than spending no energy and epic failing.
You have an epic ability to blow things out of proportion. Maybe if you looked at the anaconda source, or comps, and provided patches for what you'd like to see, not only would it be helpful, but you'd also have more code to rant about in your blogs!
Oh, were those /your/ cheerios I was pissing in?
On 23.10.2008 18:56, Jesse Keating wrote:
Neither will the meaning of 'minimal' be. Will it have networking? Will it have yum? Will it have ssh? Will it speak my language? So on, and so forth.
Not sure if my mind plays tricks with me, but I got the impression that I hear something like the above as a "shoot the discussion down" argument every few days right now... This is starting to annoy me, as statements like the above don't lead anywhere: Decisions have to be made; repeatably pointing out that it's hard to do them doesn't bring us a tiny bit further. So please:
Just let a group of interested people make a decision and realize it as a feature for F11! Then we hopefully can get rid of this topic (which seems to pop up every few weeks...).
Just my 2 cent.
Cu knurd
(¹) Just like other decisions get made every day in Fedora. "Chose the default" decisions are a good example, that are just as hard to make often: Epiphany or Firefox? Pidgin or Empathy? Thunderbird or Evolution? Some people won't like the decision in the end, but it's better for everyone to make one !
On Thu, 2008-10-23 at 19:31 +0200, Thorsten Leemhuis wrote:
Not sure if my mind plays tricks with me, but I got the impression that I hear something like the above as a "shoot the discussion down" argument every few days right now... This is starting to annoy me, as statements like the above don't lead anywhere: Decisions have to be made; repeatably pointing out that it's hard to do them doesn't bring us a tiny bit further. So please:
Just let a group of interested people make a decision and realize it as a feature for F11! Then we hopefully can get rid of this topic (which seems to pop up every few weeks...).
The "Feature" exists. You get it by de-selecting every box in anaconda. A committee of interested people aren't going to magically make new UI show up in anaconda, that has to be done through the anaconda upstream and maintainers.
On 23.10.2008 19:40, Jesse Keating wrote:
On Thu, 2008-10-23 at 19:31 +0200, Thorsten Leemhuis wrote:
Not sure if my mind plays tricks with me, but I got the impression that I hear something like the above as a "shoot the discussion down" argument every few days right now... This is starting to annoy me, as statements like the above don't lead anywhere: Decisions have to be made; repeatably pointing out that it's hard to do them doesn't bring us a tiny bit further. So please:
Just let a group of interested people make a decision and realize it as a feature for F11! Then we hopefully can get rid of this topic (which seems to pop up every few weeks...).
The "Feature" exists. You get it by de-selecting every box in anaconda.
I unsure if I agree or not, but one things seems obvious to me: The current solution doesn't satisfy a lot of people (actually "it confuses people" might be the the better description). So if there are people that want to work out a better solution please let them just do that; if you think that clutters the UI then bring that point up; but just repeatably stating that it's hard to pick the "minimal package set" doesn't bring us any further.
A committee of interested people aren't going to magically make new UI show up in anaconda, that has to be done through the anaconda upstream and maintainers.
Sounds yet again like you want to shoot the discussion down, as you make it sound like getting things into anaconda is something totally impossible. But luckily Fedora and anaconda are open-source projects; Red Hat even opened RHL/started Fedora to give the community a chance to influence and improve things like that. So give them a chance to do that; yes, it's maybe won't be easy to realize with a clean UI, but I'm optimistic it's possible somehow.
Cu knurd
On Thu, 2008-10-23 at 20:05 +0200, Thorsten Leemhuis wrote:
The "Feature" exists. You get it by de-selecting every box in anaconda.
I unsure if I agree or not, but one things seems obvious to me: The current solution doesn't satisfy a lot of people (actually "it confuses people" might be the the better description).
And so did the "minimal" offerings of past.
So if there are people that want to work out a better solution please let them just do that; if you think that clutters the UI then bring that point up; but just repeatably stating that it's hard to pick the "minimal package set" doesn't bring us any further.
I've stated over and over again that you're welcome to try. I even pointed out that Comps is the place to do it, and that is even open for commit access. So far, I haven't seen any real discussion or changes there.
A committee of interested people aren't going to magically make new UI show up in anaconda, that has to be done through the anaconda upstream and maintainers.
Sounds yet again like you want to shoot the discussion down, as you make it sound like getting things into anaconda is something totally impossible.
Not at all. However this particular thing I don't see a lot of chance of getting in, at least not in the previously suggested ways.
But luckily Fedora and anaconda are open-source projects;
As I stated.
Red Hat even opened RHL/started Fedora to give the community a chance to influence and improve things like that. So give them a chance to do that; yes, it's maybe won't be easy to realize with a clean UI, but I'm optimistic it's possible somehow.
Isn't that why I said to go through the anaconda upstream and maintainers to get such a change in?
Thorsten Leemhuis fedora@leemhuis.info wrote:
On 23.10.2008 18:56, Jesse Keating wrote:
Neither will the meaning of 'minimal' be. Will it have networking? Will it have yum? Will it have ssh? Will it speak my language? So on, and so forth.
Not sure if my mind plays tricks with me, but I got the impression that I hear something like the above as a "shoot the discussion down" argument every few days right now... This is starting to annoy me, as statements like the above don't lead anywhere: Decisions have to be made; repeatably pointing out that it's hard to do them doesn't bring us a tiny bit further. So please:
Just let a group of interested people make a decision and realize it as a feature for F11! Then we hopefully can get rid of this topic (which seems to pop up every few weeks...).
That /has/ been done (yes, I've been around since Red Hat 3.x days), and it made /never/ everybody happy, thus the recurring flamewars on the topic. When they say here that it _can't_ be solved it is not out of lazyness, it is out of (often bitter) experience.
What is minimal for me is sorely lacking while barroquely bloated for the next interested party.
On Thu, Oct 23, 2008 at 6:43 PM, Horst H. von Brand vonbrand@inf.utfsm.cl wrote:
Thorsten Leemhuis fedora@leemhuis.info wrote:
On 23.10.2008 18:56, Jesse Keating wrote:
Neither will the meaning of 'minimal' be. Will it have networking? Will it have yum? Will it have ssh? Will it speak my language? So on, and so forth.
Not sure if my mind plays tricks with me, but I got the impression that I hear something like the above as a "shoot the discussion down" argument every few days right now... This is starting to annoy me, as statements like the above don't lead anywhere: Decisions have to be made; repeatably pointing out that it's hard to do them doesn't bring us a tiny bit further. So please:
Just let a group of interested people make a decision and realize it as a feature for F11! Then we hopefully can get rid of this topic (which seems to pop up every few weeks...).
That /has/ been done (yes, I've been around since Red Hat 3.x days), and it made /never/ everybody happy, thus the recurring flamewars on the topic. When they say here that it _can't_ be solved it is not out of lazyness, it is out of (often bitter) experience.
What is minimal for me is sorely lacking while barroquely bloated for the next interested party. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
I have to agree with Jesse and Horst because I remember the "minimal" install option too and any option I chose always disappointed because I found I had to add stuff to the minimal installs and remove stuff from the other installs.
So I like what we currently have more. It builds up less expectation and therefore disappoints less. ;-) And that is all you can hope for given the extreme visability of the feature.
On Mon, 2008-10-13 at 21:48 +0200, Patrice Dumas wrote:
Indeed that will happen. But does doing nothing really prevent it from happening?
Yes, since removing the install classes, the bugs against these classes being wrong in one way shape or form have all but disappeared.
On Mon, Oct 13, 2008 at 01:12:44PM -0700, Jesse Keating wrote:
On Mon, 2008-10-13 at 21:48 +0200, Patrice Dumas wrote:
Indeed that will happen. But does doing nothing really prevent it from happening?
Yes, since removing the install classes, the bugs against these classes being wrong in one way shape or form have all but disappeared.
A very strong argument, indeed. It seems unfortunate but not unwise not to have any minimal set, then. Sigh...
-- Pat
Jesse Keating <jkeating <at> redhat.com> writes:
Yes, since removing the install classes, the bugs against these classes being wrong in one way shape or form have all but disappeared.
Sure. So let's remove the kernel, it will instantly "fix" 993 open bugs. :-D
Removing something just because it is not perfect is rarely a good solution, usually it's better to have a buggy feature than not to have it at all.
Kevin Kofler
On Mon, 2008-10-20 at 22:28 +0000, Kevin Kofler wrote:
Sure. So let's remove the kernel, it will instantly "fix" 993 open bugs. :-D
Removing something just because it is not perfect is rarely a good solution, usually it's better to have a buggy feature than not to have it at all.
Except that the "feature" only led to bugs being filed, and people always picking "custom" because they felt they always feel somewhere between the listed classes.
On Mon, 2008-10-20 at 22:28 +0000, Kevin Kofler wrote:
Jesse Keating <jkeating <at> redhat.com> writes:
Yes, since removing the install classes, the bugs against these classes being wrong in one way shape or form have all but disappeared.
Sure. So let's remove the kernel, it will instantly "fix" 993 open bugs. :-D
Removing something just because it is not perfect is rarely a good solution, usually it's better to have a buggy feature than not to have it at all.
It wasn't about removing "bugs". It was about the fact that it was fundamentally the wrong sort of place to put such a question. People's opinions of partitioning vs packaging vs how to install the bootloader, as it turns out, aren't heavily tied together. So rather than try to give an option to preset multiple later options (as well as hide some of them), it's better to just make the later options more accessible. Which is what we've attempted to do.
Jeremy
Jesse Keating wrote:
On Mon, 2008-10-13 at 21:48 +0200, Patrice Dumas wrote:
Indeed that will happen. But does doing nothing really prevent it from happening?
Yes, since removing the install classes, the bugs against these classes being wrong in one way shape or form have all but disappeared.
Which means you've successfully removed the user's ability to legitimately complain. Doesn't mean they aren't even more annoyed now then they are then.
--CJD
On Tue, 2008-10-21 at 21:54 -0400, Casey Dahlin wrote:
Which means you've successfully removed the user's ability to legitimately complain. Doesn't mean they aren't even more annoyed now then they are then.
No, it means we've stopped playing word games with users. Now when/if they have a complaint about the package set they get when they uncheck all boxes, we can deal with it at a comps level, rather than trying to play word games at the installer level with what all of comps a "minimal" install should be.
Seriously, we give people the freedom to define their own "minimal" and it works well.
On Mon October 13 2008, Jesse Keating wrote:
On Mon, 2008-10-13 at 09:29 +0200, Ralf Corsepius wrote:
You are nit-picking at words.
As was everybody who ever complained about the "minimal" install option we had.
Though a Fedora installation with yum + rpm isn't "truely minimal", it's the minimal install to keep an installation usable/maintainable.
Which is useful to some, too fat for others.
Can we make it possible to easily select the following four minimal sets? E.g. hide the first three a little and print a warning dialog when one selects them?
minimal-bootable: A Fedora systems that boots and allows to login via text or serial console and install software via rpm.
minimal-rpm: minimal-bootable + rpm
minimal-yum: A Fedora system that has also yum installed
It should be also easy to add support for ethernet network or have at least ethernet network support and make it easy to also select dial up and wireless support.
minimal-suggested: The current minimal possible set
Is it possible to design these sets for anaconda without recreating a boot image, but only e.g. pointing it to an external repo that only contains comps information?
Regards, Till
On Tue, 2008-10-14 at 00:45 +0200, Till Maas wrote:
Is it possible to design these sets for anaconda without recreating a boot image, but only e.g. pointing it to an external repo that only contains comps information?
I think you'd have a lot of "fun" trying to get the UI right for your suggestion, but as far as working with install sets vs install media, you can boot install media with repo=<something> and it will look to that repo for it's package information (including group information, and what a "default" install is) rather than the media itself, or any default repo path on the media.
2008/10/14 Jesse Keating jkeating@redhat.com:
On Tue, 2008-10-14 at 00:45 +0200, Till Maas wrote:
Is it possible to design these sets for anaconda without recreating a boot image, but only e.g. pointing it to an external repo that only contains comps information?
Even working with anaconda and doing your own spins with revisor it's not easy to get a slim F9 install. It's almost impossible to shed the gtk/xorg toolchain because anaconda pulls it in.
I think you'd have a lot of "fun" trying to get the UI right for your suggestion,
Other distros I use offer this ("desktop install", "server install" radio buttons) instead of the current anaconda sets, and hide the comps groups behind an 'advanced' option. The server install does _not_ install X.
And on a different email, Ralf Corsepius rc040203@freenet.de wrote:
Though a Fedora installation with yum + rpm isn't "truely minimal", it's the minimal install to keep an installation usable/maintainable.
Which is useful to some, too fat for others.
Well, to me a "no-yum" installation is an ignorable extremal singular case.
The embedded devices crowd uses this kind of install ("no yum, no rpm even") quite a bit, and they have a lot of overlap with the "headless server" crowd in interests. So if you don't ignore that requirement, you get a larger community of users/developers with a significant overlap with your interests :-)
Even if each group thinks that the other is crazy... the overlap is significant, and both can feed off each other.
Note! I am not arguing that such "no yum" option needs to be available from the GUI anaconda installer. That'd be pointless. I just say that it should be possible and at least somewhat supported via anaconda in combination with revisor or pungi.
Right now it does not seem to be.
cheers,
m
On Tue, Oct 14, 2008 at 04:31:20PM +1300, Martin Langhoff wrote:
Note! I am not arguing that such "no yum" option needs to be available from the GUI anaconda installer. That'd be pointless. I just say that it should be possible and at least somewhat supported via anaconda in combination with revisor or pungi.
Right now it does not seem to be.
There is a bug in anaconda that forces all build time anaconda dependencies in, until this is fixed it is not possible to come with something really small. Then we'll see once it is fixed.
-- Pat
There is a bug in anaconda that forces all build time anaconda dependencies in, until this is fixed it is not possible to come with something really small. Then we'll see once it is fixed.
And the bug number would be... ? I'm not seeing this in the code at all. The only things anaconda pulls in that aren't explicitly given by the user or the dependency of another package are: filesystem utilities, raid/iscsi/whatever if you install that, gcc if you install kernel-devel, authconfig, chkconfig, mkinitrd, rhpl, and system-config-firewall-tui.
The anaconda BuildReqs are rather extensive and includes tons of -devel packages. I don't see these getting installed in my testing.
- Chris
On Tue, Oct 14, 2008 at 09:05:56AM -0400, Chris Lumens wrote:
There is a bug in anaconda that forces all build time anaconda dependencies in, until this is fixed it is not possible to come with something really small. Then we'll see once it is fixed.
And the bug number would be... ? I'm not seeing this in the code at all. The only things anaconda pulls in that aren't explicitly given by the user or the dependency of another package are: filesystem utilities, raid/iscsi/whatever if you install that, gcc if you install kernel-devel, authconfig, chkconfig, mkinitrd, rhpl, and system-config-firewall-tui.
I couldn't find it, but Jesse responded in the same thread that the bug is closed now. And as Jesse said, it was an issue with composition rather than with anaconda itself.
-- Pat
On Tue, 2008-10-14 at 16:31 +1300, Martin Langhoff wrote:
Even working with anaconda and doing your own spins with revisor it's not easy to get a slim F9 install. It's almost impossible to shed the gtk/xorg toolchain because anaconda pulls it in.
I do believe that's just a compose tool problem, and one that I do believe is fixed in rawhide. You no longer need any of anaconda's deps in your compose payload/manifest, as buildinstall will bring in what it needs to create the graphical install images at compose time. Your images (stage2) will have the graphical stuff, but not your install payload.
On Mon, 2008-10-13 at 08:29 -0700, Jesse Keating wrote:
On Mon, 2008-10-13 at 09:29 +0200, Ralf Corsepius wrote:
You are nit-picking at words.
As was everybody who ever complained about the "minimal" install option we had.
Though a Fedora installation with yum + rpm isn't "truely minimal", it's the minimal install to keep an installation usable/maintainable.
Which is useful to some, too fat for others.
Well, to me a "no-yum" installation is an ignorable extremal singular case.
And yes, the fact yum pulls in python is a real problem on small systems. Even worse are the system-config-* tools, most of which pull in many more packages and don't even work without X.
Congratulations you've just walked into a decade + argument.
I don't see this.
Probably because you haven't been on the front line, taking the bug reports, talking to users at events,
Right.
trying to tweak the targets to match expectation and continually failing because there is no singular expectation.
Right, there is no singular expectation. But what Fedora currently offers is not even an approximation of a minimal install.
What I am looking for as "minimal install", is a default configuration, which is just sufficient to boot up into a root shell and launch yum, such one can start to taylor an install set to personal demands.
Ralf
On Tue, 2008-10-14 at 04:40 +0200, Ralf Corsepius wrote:
Right, there is no singular expectation. But what Fedora currently offers is not even an approximation of a minimal install.
So lets see some comps patches for the @core group, because @core is what you describe, and what you'd get if you unchecked all the boxes during an interactive install, or just had %packages --nobase in kickstart. Please tell me how this doesn't meet your definition of 'minimal'.
Jesse Keating <jkeating <at> redhat.com> writes:
So lets see some comps patches for the @core group, because @core is what you describe, and what you'd get if you unchecked all the boxes during an interactive install, or just had %packages --nobase in kickstart. Please tell me how this doesn't meet your definition of 'minimal'.
It isn't available without kickstart.
Kevin Kofler
On Mon, 2008-10-20 at 22:31 +0000, Kevin Kofler wrote:
It isn't available without kickstart.
Incorrect. You can de-select every check box in the 'Customize now' screen and have %packages --nobase. You can check just the Base group and have %packages.
Again, what is missing?
Ralf Corsepius <rc040203 <at> freenet.de> writes:
And yes, the fact yum pulls in python is a real problem on small systems. Even worse are the system-config-* tools, most of which pull in many more packages and don't even work without X.
Help us get the zypper stack in then: https://bugzilla.redhat.com/show_bug.cgi?id=447740 I can ask Lorenzo what still needs to be done.
Unfortunately, it will probably never be considered as a default, even for a minimal installation. :-( But it could be used on custom kickstarts.
I'd also suggest the good old apt-rpm, but unfortunately I'm not sure if it works with the new RPM in F10 (Panu told me at FUDCon Brno that there's some fun stuff like Lua version conflicts).
Kevin Kofler
On Mon, 2008-10-20 at 22:41 +0000, Kevin Kofler wrote:
Ralf Corsepius <rc040203 <at> freenet.de> writes:
And yes, the fact yum pulls in python is a real problem on small systems. Even worse are the system-config-* tools, most of which pull in many more packages and don't even work without X.
Help us get the zypper stack in then: https://bugzilla.redhat.com/show_bug.cgi?id=447740 I can ask Lorenzo what still needs to be done.
AIUI zypper doesn't resolve file deps. (SuSE just don't have them) ... so while I personally wouldn't mind being able to yum install it and play with it, I don't think we should recommend it's use.
And that's even if having two different depsolvers/pacakge-managers supported at once wasn't complete crack, which it is.
Unfortunately, it will probably never be considered as a default, even for a minimal installation. :-( But it could be used on custom kickstarts.
I'd also suggest the good old apt-rpm, but unfortunately I'm not sure if it works with the new RPM in F10 (Panu told me at FUDCon Brno that there's some fun stuff like Lua version conflicts).
apt seems to crash a lot, for me, YMMV. And that's even if having two different...
Ralf Corsepius пишет:
On Fri, 2008-10-10 at 15:31 -0700, Jesse Keating wrote:
On Sat, 2008-10-11 at 00:25 +0200, Ralf Corsepius wrote:
Great, now get consensus on what 'minimal' should be.
shell + networking.
Approximately the set of packages required for a networked install.
And does that include the ability to add more later?
Sure, yum + rpm are a requirement.
Ralf
No, only rpm is needed. So, yum may be safely installed later by rpm.
Everything can be done after installation of Fedora, but time is precious . Installation of fedora first then again install packages needed by a server or a desktop is time consuming. I think we should keep in mind that kickstart files can be a solution for a advanced linux users not for new linux users.
Why are we making fedora a OS for advanced linux users ? I think the new layout will help new fedora users a lot . Personally I think we should concentrate on "ease of use" concept. I am currently working on the options layout, and what packages can be provided under each option.
Yours sincerely ,
Shambo Bose.
On Fri, 2008-10-10 at 23:17 +0530, Shambo Bose wrote:
I am currently working on the options layout, and what packages can be provided under each option.
Please note, that Red Hat Linux used to offer these options, and eventually they were so blurred as to not really make any sense. I suspect history would repeat itself.
On Fri, 2008-10-10 at 12:37 -0700, Jesse Keating wrote:
On Fri, 2008-10-10 at 23:17 +0530, Shambo Bose wrote:
I am currently working on the options layout, and what packages can be provided under each option.
Please note, that Red Hat Linux used to offer these options, and eventually they were so blurred as to not really make any sense. I suspect history would repeat itself.
To be more explicit -- between user testing, bug reports, mailing lists, forums, etc we realized that just about everyone picked "Custom" because they figured they had something that made them different or special.
Realistically, we actually still have install options like this -- it's just now more about picking a live image to start from rather than selecting something within the installer. And if you're doing the install from DVD or from the network, chances are that you're exactly the sort of person that would be picking custom :-) "Desktop-y" users should be going more for the live images and the download page is trying to push them in that direction[1]
Jeremy
[1] And for Fedora 10, that will be even more the case from the mockups thus far