On Sun, Sep 16, 2012 at 1:05 PM, Ned Slider <ned at unixmail.co.uk> wrote: > > >> If it is included, it can be patched. Debian/ubuntu do this somewhat >> sensibly but there you have to make a one-time selection to enable the >> extra repos. I think it is nicer to keep the alternative ones (except >> maybe EPEL) disabled. >> > > As a repo provider, if you patch it you can support it as it's no longer > what I ship. I don't want the extra support load when you break what I ship. If setting a repo file to enabled=0 breaks something, then no one should be using it in the first place. As for support, does that mean you'll come fix my box when a different 3rd part repo adds a package with the same name and the packages clobber each other during updates? If not, how is not having your support any different? > Which is pretty much the same response you'll hear from CentOS every > time someone posts with a system running a non-CentOS kernel. And yet, everyone has policies that keep them from accepting all packages into one repository. Lovely... And worse, where the point of the repo is to supply updated packages, they often aren't renamed and intentionally conflict with others. > IMHO that's not what CentOS wants here. It's certainly not what 3rd > party repo providers would want either. I'm sure it isn't. But it would serve the users that need packages they each refuse to accept. > Besides, your approach simply won't work. If you were to install an > edited (patched) repo file set to enabled=0, the first time a user runs > 'yum update' and the repo file gets updated from the repo the user will > be back at the repo's default settings regardless of how the distro may > or may not have initially patched the repo file. Hmmm, that seems like a bug. Should rpm packages clobber user configurations? > It's simply not your config file to alter so if you don't like the > defaults don't ship it. Make that a criteria from the start together > with guidance on what defaults are acceptable for inclusion. The underlying problem is that there is no correct way to deal with uncoordinated repositories. Maybe someone could tackle that problem. Coordination seems to have failed even in the simple cases where the idea is to be conflict-free. Maybe a brute-force test integration against all known repositories and all packages could come up with a matrix of what works together and what doesn't. -- Les Mikesell lesmikesell at gmail.com