On Wed, Feb 26, 2014 at 10:20 AM, Jim Perrin <jperrin at centos.org> wrote: > >> Is it better to have users COMPILE FROM SOURCE???? Because they f***ing DO! > > Not one single person has ever said that in this discussion. That's not > even what this is about. This is about including packages in the CORE > (yes, extras is enabled by default) distribution. I say that. And it is about the problem of easily creating yum conflicts with a mix of repositories. I think that problem deserves some effort to fix. > If a sig wants to create a 'centos-enhanced' distribution and pull these > repos in, that's entirely fine. I don't have a single problem with that > and would happily support it. That's entirely the point of the > SIG/variant framework. However we've always been protective of the core > distribution, and that's one of the reasons it's been successful. The base portion isn't even part of the problem, though. >> By the way, RepoForge is practically dead in the water so no need using >> it as EPEL vs Repoforge argument. If you were to create a poll on forums >> (2-3 weeks of announcement in advance would be enough to rally all for >> and against) where you would ask: > > Fine substitute any other repository name out there. There are dozens to > choose from. Hence the problem. Which set will provide the package a new user will almost certainly need and never break their update? How much time would it take to explain this correctly to a new user? How much damage will it do when yum stops updating? > Still missing the point. It's not a popularity contest. Yes, those two > win hands down. It's about establishing a baseline or metric so that > OTHER repos might work toward gaining that same level of > acceptance/trust, AND making sure we don't allow conflicting repos by > default, thus breaking yum update. Would it be possible to automate checking the entire contents of multiple repositories? That is, without actually merging the repos, check that there are no missing/conflicting dependencies or contents (probably with EPEL as a requirement), no duplicate package names with differing contents, or anything else that might either break yum or cause surprises from replaced packages. Maybe just having an objective validator and some repo manager cooperation would fix things. > Again, this is EXACTLY the point of the SIG/variant concept. I > challenged you before to do this exact thing for a desktop sig. Would/could, the permissible contents be different for a SIG than for EPEL? Could a SIG variant include, say, vlc or equivalent media players? >> Maybe even "What is a proper way to do things" video that explains >> differences to other distro's for users that are coming from >> Ubuntu/Debian/Mint could help such transitions. > > Dunno about a video, but I am working on a wiki page that deals with the > various command translations ( apt-get install foo -> yum install foo). And what are you going to suggest as a replacement for the repositories Ubuntu would let you enable? >> Also worth thinking about is rebuilding EPEL and ElRepo packages inside >> CentOS build system, so control is absolute that it will not mess up >> anything. > > > We have been thinking about this, at least with EPEL. There are pitfalls > with doing this as well. Control is not absolute, as we do not own EPEL. > If we duplicate it, and adjust a package then we're a fork and we're > back to the same old interoperability discussion again depending on > what's changed, versions, and/or build deps. It is the inclusion policy that is the problem with EPEL - the technical side is fine. And I see less chance than ever of changing that. -- Les Mikesell lesmikesell at gmail.com