On 02/26/2014 10:47 AM, Les Mikesell wrote: > 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? > It has to be something that we can legally distribute from a US law perspective. If it fits that criteria, then yes. >>> 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? The same repositories we already list via the wiki. >>> 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. > We don't have the same restrictions that EPEL does, so the barrier to entry should be lower. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77