I am just suggesting a new opinion on centos server. During the installation, why cant you add a check or click all box to select all packages you are going to install when choosing packages or service you want to install in the server. i have to do the clicking on 1 at a time just to install like 300 or more packages.
Its just my sugestion
Thank you
Hi,
On 07/29/2011 11:05 AM, cephas kamuchira wrote:
I am just suggesting a new opinion on centos server. During the installation, why cant you add a check or click all box to select all packages you are going to install when choosing packages or service you want to install in the server. i have to do the clicking on 1 at a time just to install like 300 or more packages.
I suspect there is no reply to your email, since not many people were able to completely understand your point. Are you saying that when a group is selected, all rpms in that group ( mandatory and optional ) should be automatically selected ?
- KB
On 08/02/2011 12:37 PM, Karanbir Singh wrote:
Hi,
On 07/29/2011 11:05 AM, cephas kamuchira wrote:
I am just suggesting a new opinion on centos server. During the installation, why cant you add a check or click all box to select all packages you are going to install when choosing packages or service you want to install in the server. i have to do the clicking on 1 at a time just to install like 300 or more packages.
I suspect there is no reply to your email, since not many people were able to completely understand your point. Are you saying that when a group is selected, all rpms in that group ( mandatory and optional ) should be automatically selected ?
- KB
Something like that, probably. An option to select/unselect all packages did exist in the installer a long time ago.
On 02/08/2011 10:37, Karanbir Singh wrote:
Hi,
On 07/29/2011 11:05 AM, cephas kamuchira wrote:
I am just suggesting a new opinion on centos server. During the installation, why cant you add a check or click all box to select all packages you are going to install when choosing packages or service you want to install in the server. i have to do the clicking on 1 at a time just to install like 300 or more packages.
I suspect there is no reply to your email, since not many people were able to completely understand your point. Are you saying that when a group is selected, all rpms in that group ( mandatory and optional ) should be automatically selected ?
I am assuming that he means to suggest a button to "select all" in a group. Right now on certain groups when you select them for installation will only install for example 11/93, I think he means to add a button that allows him to add the other 82 in a single click.
rgds,
Roeland
On 08/02/2011 06:44 PM, Roeland Mertens wrote:
On 02/08/2011 10:37, Karanbir Singh wrote:
Hi,
On 07/29/2011 11:05 AM, cephas kamuchira wrote:
I am just suggesting a new opinion on centos server. During the installation, why cant you add a check or click all box to select all packages you are going to install when choosing packages or service you want to install in the server. i have to do the clicking on 1 at a time just to install like 300 or more packages.
I suspect there is no reply to your email, since not many people were able to completely understand your point. Are you saying that when a group is selected, all rpms in that group ( mandatory and optional ) should be automatically selected ?
I am assuming that he means to suggest a button to "select all" in a group. Right now on certain groups when you select them for installation will only install for example 11/93, I think he means to add a button that allows him to add the other 82 in a single click.
We had this discussion in Fedora-land a while back. There are pretty solid reasons why this was removed in Fedora and later RHEL as an option (the FESCo logs of it are around somewhere, as are a few blogs detailing this after the fact).
Installing *everything* is not normal use and can cause weird things to happen (depending on use -- for example when alternatives install next to or over defaults and admins often don't realize this is happening, particularly with sendmail/postfix or 389-DS/OpenLDAP).
...and for people who *really* want to do this, 'yum install"*"' works just fine and lets you know a lot more than Anaconda does. The quotes around the * are necessary. This can be placed in a kickstart script or a firstrun hack but neither tier of upstream consider it a good idea to tempt the average person installing a system with such a nuclear option before they've even seen the system defaults working the way they were designed...
Anyway, wouldn't this break "binary compatibility with upstream"?
Just my $20
-Iwao
On 8/2/2011 10:28 AM, 夜神 岩男 wrote:
I am assuming that he means to suggest a button to "select all" in a group. Right now on certain groups when you select them for installation will only install for example 11/93, I think he means to add a button that allows him to add the other 82 in a single click.
We had this discussion in Fedora-land a while back. There are pretty solid reasons why this was removed in Fedora and later RHEL as an option (the FESCo logs of it are around somewhere, as are a few blogs detailing this after the fact).
Installing *everything* is not normal use and can cause weird things to happen (depending on use -- for example when alternatives install next to or over defaults and admins often don't realize this is happening, particularly with sendmail/postfix or 389-DS/OpenLDAP).
It would be nice if someone who chose the available packages and has at least some understanding of them would also provide an 'everything' choice that is a set of all the package that won't cause weird things to happen. Disk space is cheap and it is much easier to explore/test programs when they are installed than by reading the itty-bitty blurb that 'yum info' gives. Was there anyone in the fedora-land discussion who thought an end user would really be able to select packages sight-unseen better than the people who made the choice of packages to be included in the distro?
...and for people who *really* want to do this, 'yum install"*"' works just fine and lets you know a lot more than Anaconda does. The quotes around the * are necessary. This can be placed in a kickstart script or a firstrun hack but neither tier of upstream consider it a good idea to tempt the average person installing a system with such a nuclear option before they've even seen the system defaults working the way they were designed...
Anyway, wouldn't this break "binary compatibility with upstream"?
Agreed - it is something that upstream should provide too. Or at least a yum group or list of packages in a form that yum would understand to install them later.
On 08/02/2011 05:01 PM, Les Mikesell wrote:
Anyway, wouldn't this break "binary compatibility with upstream"?
Agreed - it is something that upstream should provide too. Or at least a yum group or list of packages in a form that yum would understand to install them later.
So the interesting thing about that is - that no, it wont break upstream compatibility; since the groups that are put in are done by us - remember that upstream has varients that we dont, and their process and policy around those varients depends on various non technical factors ( eg. how much money you paid for the subscription that in turn got you the install media ).
Lets say, its a bit of a grey area - we *could* have that as an option if people *really* wanted it. I suspect a yum install * in the %post of a ks.cfg would achieve about the same result.
- KB
On 08/03/2011 01:19 AM, Karanbir Singh wrote:
On 08/02/2011 05:01 PM, Les Mikesell wrote:
Anyway, wouldn't this break "binary compatibility with upstream"?
Agreed - it is something that upstream should provide too. Or at least a yum group or list of packages in a form that yum would understand to install them later.
So the interesting thing about that is - that no, it wont break upstream compatibility; since the groups that are put in are done by us - remember that upstream has varients that we dont, and their process and policy around those varients depends on various non technical factors ( eg. how much money you paid for the subscription that in turn got you the install media ).
Lets say, its a bit of a grey area - we *could* have that as an option if people *really* wanted it. I suspect a yum install * in the %post of a ks.cfg would achieve about the same result.
And this was the route opted for. The folks who understand how to do that are the ones who are safest doing it. Sort of like putting a child-lock on the brain-eating entropy machine that a system this large and diverse can become.
-Iwao
Karanbir Singh wrote:
On 08/02/2011 05:01 PM, Les Mikesell wrote:
Anyway, wouldn't this break "binary compatibility with upstream"?
Agreed - it is something that upstream should provide too. Or at least a yum group or list of packages in a form that yum would understand to install them later.
So the interesting thing about that is - that no, it wont break upstream compatibility; since the groups that are put in are done by us - remember that upstream has varients that we dont, and their process and policy around those varients depends on various non technical factors ( eg. how much money you paid for the subscription that in turn got you the install media ).
Is it possible to create yum groups that overlap with other groups? So we/they/whoever could add several selected groups. This means that one package could be in several groups.
On 08/03/2011 01:32 AM, Ljubomir Ljubojevic wrote:
Karanbir Singh wrote:
On 08/02/2011 05:01 PM, Les Mikesell wrote:
Anyway, wouldn't this break "binary compatibility with upstream"?
Agreed - it is something that upstream should provide too. Or at least a yum group or list of packages in a form that yum would understand to install them later.
So the interesting thing about that is - that no, it wont break upstream compatibility; since the groups that are put in are done by us - remember that upstream has varients that we dont, and their process and policy around those varients depends on various non technical factors ( eg. how much money you paid for the subscription that in turn got you the install media ).
Is it possible to create yum groups that overlap with other groups? So we/they/whoever could add several selected groups. This means that one package could be in several groups.
I think that happens pretty regularly and should be as harmless as
yum install $EXISTING_PACKAGE
-Iwao
On 08/03/2011 01:01 AM, Les Mikesell wrote:
On 8/2/2011 10:28 AM, 夜神 岩男 wrote:
I am assuming that he means to suggest a button to "select all" in a group. Right now on certain groups when you select them for installation will only install for example 11/93, I think he means to add a button that allows him to add the other 82 in a single click.
We had this discussion in Fedora-land a while back. There are pretty solid reasons why this was removed in Fedora and later RHEL as an option (the FESCo logs of it are around somewhere, as are a few blogs detailing this after the fact).
Installing *everything* is not normal use and can cause weird things to happen (depending on use -- for example when alternatives install next to or over defaults and admins often don't realize this is happening, particularly with sendmail/postfix or 389-DS/OpenLDAP).
It would be nice if someone who chose the available packages and has at least some understanding of them would also provide an 'everything' choice that is a set of all the package that won't cause weird things to happen. Disk space is cheap and it is much easier to explore/test programs when they are installed than by reading the itty-bitty blurb that 'yum info' gives. Was there anyone in the fedora-land discussion who thought an end user would really be able to select packages sight-unseen better than the people who made the choice of packages to be included in the distro?
...and for people who *really* want to do this, 'yum install"*"' works just fine and lets you know a lot more than Anaconda does. The quotes around the * are necessary. This can be placed in a kickstart script or a firstrun hack but neither tier of upstream consider it a good idea to tempt the average person installing a system with such a nuclear option before they've even seen the system defaults working the way they were designed...
Anyway, wouldn't this break "binary compatibility with upstream"?
Agreed - it is something that upstream should provide too. Or at least a yum group or list of packages in a form that yum would understand to install them later.
This was discussed, exactly the way you are stating things on one side "wouldn't it be nice if..." VS "the uninformed are the majority who choose the 'everything' option and when things break they assume the whole distro sucks and ditch it" on the other.
Which would you prefer be the newcomer impression of CentOS? A system that works well with adequate defaults but that can be explored to the heart's content (which entails research -- on any OS -- how many people do "everything" AIX installs -- they either don't do them or receive AIX package selections that are strict defaults with nothing further vendor-provided?) or one that gets overloaded with conflicts and breaks because too many conflicts are installed and things that are supposed to be simple, like starting or stopping slapd, become complex in ways unknowable to the user?
In short:
The chance that a knowledgable system administrator is going to be able to research how packages interact in a desired setup...
...is a lot higher than...
...the chances that the average person who is prone to click "everything" will know how to manage the situation he's put himself in.
This *was* a feature in the past and was removed for a reason. You can head back to FESCo and re-argue it, but I found the case for removal compelling, particularly with the 'yum install "*"' option available for those who know what they are doing -- and that begins with understanding why the "s are necessary in the command.
This was a revealing threshold, as it turned out once the feature was removed -- most of the complaints/questions on the users@fp.o list about removal were from people who really didn't know what quotes do in bash... which sort of validated the whole debate in favor of removal after the fact. This was the precise demographic that had no business clicking "everything" and was the only group clamoring for the reinstatement of @everything.
As far as package preselects or package groups that are known to work well together, Anaconda is replete with them. A cut down of an @everything option winds up being a lot closer to a spin than an installation option, and that is where those things have drifted to (Well, more in Fedora land than CentOS land. Most CentOS folks tend to just use the distro and not develop spins.).
There is history behind this decision. Of course, CentOS is not upstream, so it could go its own way, but I think thoughtful contemplation of the issue at hand (making a dangerous edgecase widely available on an enterprise-level system) they will likely stick with the status quo.
-Iwao
On 8/2/2011 11:25 AM, 夜神 岩男 wrote:
Agreed - it is something that upstream should provide too. Or at least a yum group or list of packages in a form that yum would understand to install them later.
This was discussed, exactly the way you are stating things on one side "wouldn't it be nice if..." VS "the uninformed are the majority who choose the 'everything' option and when things break they assume the whole distro sucks and ditch it" on the other.
It's not an either/or decision if someone who understands the potentially conflicting packages picks one (and only one) to include in the 'everything' set.
Which would you prefer be the newcomer impression of CentOS? A system that works well with adequate defaults but that can be explored to the heart's content (which entails research -- on any OS -- how many people do "everything" AIX installs -- they either don't do them or receive AIX package selections that are strict defaults with nothing further vendor-provided?) or one that gets overloaded with conflicts and breaks because too many conflicts are installed and things that are supposed to be simple, like starting or stopping slapd, become complex in ways unknowable to the user?
In short:
The chance that a knowledgable system administrator is going to be able to research how packages interact in a desired setup...
...is a lot higher than...
...the chances that the average person who is prone to click "everything" will know how to manage the situation he's put himself in.
What situation would that be if someone vetted the packages and 'everything' didn't include conflicts? Wasting a dollar's worth of disk space?
This *was* a feature in the past and was removed for a reason. You can head back to FESCo and re-argue it, but I found the case for removal compelling, particularly with the 'yum install "*"' option available for those who know what they are doing -- and that begins with understanding why the "s are necessary in the command.
Ummm, _what_?
This was a revealing threshold, as it turned out once the feature was removed -- most of the complaints/questions on the users@fp.o list about removal were from people who really didn't know what quotes do in bash... which sort of validated the whole debate in favor of removal after the fact. This was the precise demographic that had no business clicking "everything" and was the only group clamoring for the reinstatement of @everything.
'everything' should not mean "*". It should mean everything that is sensible, according to someone who actually is familiar with all of them. I'd be perfectly happy if it didn't include *gcj*, for example, since I can't imagine that as ever having been good for anyone. And while I'd prefer sendmail over postscript I'd be able to deal with someone else making an informed choice there.
There is history behind this decision. Of course, CentOS is not upstream, so it could go its own way, but I think thoughtful contemplation of the issue at hand (making a dangerous edgecase widely available on an enterprise-level system) they will likely stick with the status quo.
I know there is a history. I used to use everything installs, found it useful in discovering and testing programs, miss it, and don't believe that the people you think you are 'protecting' by omitting it are going to do better at choosing non-conflicting sets by themselves given yum and a list of thousands of package names than someone who was involved in choosing the set included in the distribution could.
But, something else that I've always wanted to see might be even better. I've always thought that there should be a push-button way to export your list of installed packages (and I suppose this should include repositories...) so that anyone who thinks he has configured the perfect setup for any particular usage could publish it, and anyone who wanted to duplicate that setup could do it in a completely automated way.
On 08/03/2011 01:54 AM, Les Mikesell wrote:
On 8/2/2011 11:25 AM, 夜神 岩男 wrote:
Agreed - it is something that upstream should provide too. Or at least a yum group or list of packages in a form that yum would understand to install them later.
This was discussed, exactly the way you are stating things on one side "wouldn't it be nice if..." VS "the uninformed are the majority who choose the 'everything' option and when things break they assume the whole distro sucks and ditch it" on the other.
It's not an either/or decision if someone who understands the potentially conflicting packages picks one (and only one) to include in the 'everything' set.
Then it wouldn't be @everything, now would it?
And that is how spins get born.
In short:
The chance that a knowledgable system administrator is going to be able to research how packages interact in a desired setup...
...is a lot higher than...
...the chances that the average person who is prone to click "everything" will know how to manage the situation he's put himself in.
What situation would that be if someone vetted the packages and 'everything' didn't include conflicts? Wasting a dollar's worth of disk space?
Once again, removing something from everything makes it not everything, it makes it a "functional subset" known sometimes as a "system default installation" or a "spin" depending on how extensive the selections divert from the upstream view.
This *was* a feature in the past and was removed for a reason. You can head back to FESCo and re-argue it, but I found the case for removal compelling, particularly with the 'yum install "*"' option available for those who know what they are doing -- and that begins with understanding why the "s are necessary in the command.
Ummm, _what_?
You are underestimating the general public's ability to be fickle about technology they get for free yet do not understand.
'everything' should not mean "*". It should mean everything that is sensible, according to someone who actually is familiar with all of them. I'd be perfectly happy if it didn't include *gcj*, for example, since I can't imagine that as ever having been good for anyone. And while I'd prefer sendmail over postscript I'd be able to deal with someone else making an informed choice there.
And how is upstream to read your mind and know to not include gcj for your concept of "everything" and exclude something else for someone else's view of "everything". This sort of gets to the root of the problem. I think we're having an Aristotle moment in logical semantics where everything equals everything and not something other than everything.
I know there is a history. I used to use everything installs, found it useful in discovering and testing programs, miss it, and don't believe that the people you think you are 'protecting' by omitting it are going to do better at choosing non-conflicting sets by themselves given yum and a list of thousands of package names than someone who was involved in choosing the set included in the distribution could.
But yum install "*" hasn't gone away. Are you saying this is too hard?
But, something else that I've always wanted to see might be even better. I've always thought that there should be a push-button way to export your list of installed packages (and I suppose this should include repositories...) so that anyone who thinks he has configured the perfect setup for any particular usage could publish it, and anyone who wanted to duplicate that setup could do it in a completely automated way.
Now you're talking. This is a great idea -- and I don't know a way of doing this other than through a script that parses the output of "yum list installed" -- which is something I did once upon a time to create .ks files with a little more ease than I had been doing. A lot of people do the same thing by being very patient with a click-through Anaconda install and getting the list from the generated .ks file, but that is sort of a pain and doesn't tell you anything about what you discovered after the installation, which I think is your real point.
I never made the leap to making it a push-button feature on the desktop (though that would be easy now that its thought of) or moving as far as to think of exporting the output into an Anaconda profile selection (the way you can select "workstation" or "development" or "server" or "minimal") -- but that would be pretty cool too and perhaps more cleanly achieve the effect you're after.
-Iwao
On 8/2/2011 12:23 PM, 夜神 岩男 wrote:
It's not an either/or decision if someone who understands the potentially conflicting packages picks one (and only one) to include in the 'everything' set.
Then it wouldn't be @everything, now would it?
Call it "everything that's not broken" then.
And that is how spins get born.
That's the reason spins need to be born. Because there's not a good way to manage a list of packages. Well, that and repository policies that pretty much guarantee that you'll need packages from third party repos. Almost anything that spins can do could be done with a minimal install to the point that yum works and a package list.
This *was* a feature in the past and was removed for a reason. You can head back to FESCo and re-argue it, but I found the case for removal compelling, particularly with the 'yum install "*"' option available for those who know what they are doing -- and that begins with understanding why the "s are necessary in the command.
Ummm, _what_?
You are underestimating the general public's ability to be fickle about technology they get for free yet do not understand.
No, I'm saying the people who haven't already memorized all of bash's quirky syntax rules are precisely the ones who would benefit most from having the largest working set of programs dropped in their lap to explore, man pages and all. And leaving them on their own to figure out which few were the ones that you already know are bad to install together is a disservice.
'everything' should not mean "*". It should mean everything that is sensible, according to someone who actually is familiar with all of them. I'd be perfectly happy if it didn't include *gcj*, for example, since I can't imagine that as ever having been good for anyone. And while I'd prefer sendmail over postscript I'd be able to deal with someone else making an informed choice there.
And how is upstream to read your mind and know to not include gcj for your concept of "everything" and exclude something else for someone else's view of "everything".
That should be an 'informed' decision. I'm assuming that the person/group who decides what packages are to be included knows something about them, but why assume that about anyone else? You don't have to read my mind to know why gcj is wrong to inflict on people, just try to run a standard java program with it.
This sort of gets to the root of the problem. I think we're having an Aristotle moment in logical semantics where everything equals everything and not something other than everything.
No, there are people who know what things don't belong together (hence the point that "*" or a real 'everything" is bad). But that should not lead to a conclusion that they should leave the rest of the world to make that discovery the hard way by omitting a choice that installs all the programs that do work together.
I know there is a history. I used to use everything installs, found it useful in discovering and testing programs, miss it, and don't believe that the people you think you are 'protecting' by omitting it are going to do better at choosing non-conflicting sets by themselves given yum and a list of thousands of package names than someone who was involved in choosing the set included in the distribution could.
But yum install "*" hasn't gone away. Are you saying this is too hard?
No, I'm saying it is not quite the right set, and the person/group who decided 'everything' is bad knew why. Discovering why by myself might be hard, though.
But, something else that I've always wanted to see might be even better. I've always thought that there should be a push-button way to export your list of installed packages (and I suppose this should include repositories...) so that anyone who thinks he has configured the perfect setup for any particular usage could publish it, and anyone who wanted to duplicate that setup could do it in a completely automated way.
Now you're talking. This is a great idea -- and I don't know a way of doing this other than through a script that parses the output of "yum list installed" -- which is something I did once upon a time to create .ks files with a little more ease than I had been doing. A lot of people do the same thing by being very patient with a click-through Anaconda install and getting the list from the generated .ks file, but that is sort of a pain and doesn't tell you anything about what you discovered after the installation, which I think is your real point.
Usually it takes a lot of fiddling to get the right set in the first place, especially when you need to try some from different 3rd party repos and work around the likely conflicts there.
I never made the leap to making it a push-button feature on the desktop (though that would be easy now that its thought of) or moving as far as to think of exporting the output into an Anaconda profile selection (the way you can select "workstation" or "development" or "server" or "minimal") -- but that would be pretty cool too and perhaps more cleanly achieve the effect you're after.
I think this could work on two levels - one as a local tool to duplicate machines (and perhaps it should include package version information to hold the update levels together) and another to mostly replace the concept of spins with a public central location to publish package lists with some commentary on why you chose that particular set and what has to be done to configure them.
Les Mikesell wrote:
'everything' should not mean "*". It should mean everything that is sensible, according to someone who actually is familiar with all of them. I'd be perfectly happy if it didn't include *gcj*, for example, since I can't imagine that as ever having been good for anyone. And while I'd prefer sendmail over postscript I'd be able to deal with someone else making an informed choice there.
You meant "postfix" in last sentence?
-
cephas kamuchira -
Karanbir Singh -
Les Mikesell -
Ljubomir Ljubojevic -
Manuel Wolfshant -
Roeland Mertens -
夜神 岩男