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