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.