On Wed, Feb 26, 2014 at 1:41 PM, Alexander Arlt <centos at track5.de> wrote: > >> If good framework is established (3rd party repository wise), then that >> stuff can be in some other repository. But in order to do so, there has >> to be easy to manage repository hierarchy, without too much messing with >> yum config files. > > We're talking about a seven line config file in /etc/yum.repos.d to add > a new repository. And honestly, if I don't know what I'm doing the, it > might be a good idea to not do it. Learning curve or not. The physical setup isn't a big deal. Knowing which are a good idea is pretty much impossible. > I have broken an awful lot of installations in my professional life by > adding some repo to fix one thing and breaking ten other things. The > luxury of doing some yum install <blabumm> comes at the price of > understanding the complexity of solving the dependencies. You can't really understand the future interactions of multiple uncoordinated things. But this is not something that every individual user should have gamble on independently or work out separate solutions for frequently-needed configurations. >> Jim, you have challenged me, but to tie my hands behind my back and grab >> a rope, because without ability to install "illegal" 3rd party >> repository (vlc, gstreamer-bad, ...) without any hassle, there is no >> point in wasting any time on Desktop SIG. > > Maybe, just maybe, a Community Enterprise OS is just not the right > choice for this? And maybe, just maybe, putting wings on a cow won't > turn it into a proper bird. Maybe the US isn't the right location for it, or a US company the right management entity. > Honestly, why would anybody try to turn something like RHEL 6 into a > Desktop, with all those old kernel-stuff, the old libraries and all the > fuss you have to cope with - and still end up with something that will > not be able to run all the latest gimmicks with the complete set of > bells and whistles? I think this discussion is more about RHEL7 and the future. And if it goes anywhere there should be one solution for coordinating technically non-conflicting packages that can't be hosted in the US and something different - on the order of RHEL software collections - for managing alternative/newer package versions that would otherwise conflict, but likewise with some central vetting to avoid conflicts. -- Les Mikesell lesmikesell at gmail.com