Stupid question redux. With some more explanation Why not? Make a mirror of the epel repo. For each package in the repo. Create a repotag using the original signature. Sign the package with repotag using a new key. Anyone wanting to mix repos. Should require signatures with the new key. Problems will certainly remain, but I think this will help with some of the problems. On 7/30/07, Les Mikesell <lesmikesell at gmail.com> wrote: > > R P Herrold wrote: > > >>> ATM we'll just live and let live, and there will not be any one-side > >>> effort to rectify any compatibility issues EPEL created. It's their > >>> mess, they'll have to clean it up. > >> > >> Live and let die, you mean - at least as far as the users are > >> concerned. I don't think this issue has any solution other than > >> separate namespaces. > > > > Les > > > > Your issue belongs on another list > > Sorry, but I believe that the people affected need to know about it at > least as much as the people who control it. > > > -- the 'mark by nameing' the rpm's in > > a way obvious to a low sophistication user (rather than some checksum > > based method that does not exist) has been proposed and rejected > already. > > That misses the point that there may very well be reasons to want to > have more than one version installed at once. Every developer should > know that there are times you need to at least test 2 different versions > of something on the same machine - and they generally know how to do > it so they don't conflict. Sadly, the FHS guys seem to live on some > planet of perfection where real world issues of version differences and > places to store them don't exist, and packagers have followed along with > this mistake. > > > sad, but still the case. We'll be having pain for this for years and > > years. See: > > https://www.redhat.com/archives/epel-devel-list/2007-June/msg00031.html > > > > > Please read the archive and the back thread leading up to it. Several > > @redhat.com showed up to pack the gallery at the 'last chance' epel > > meeting which could have avoided this train wreck > > Reasons for disagreements are pretty much irrelevant to their effect. > There is not much reason to ever expect everyone to agree and lots of > reasons to provide a mechanism to allow them to disagree in separate > spaces. Try to imagine what the internet would be like if DNS did not > provide managed hierarchal namespace and anyone could usurp anyone > else's domain. That's what we get when different people can put > different contents into packages of the same names. And it isn't going > to go away until there is a namespace based system that lets the end > user choose which he wants. I'd just like to see a little less > granularity in that namespace than centos vs. ubuntu... > > -- > Les Mikesell > lesmikesell at gmail.com > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos > -- Drew Einhorn -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20070730/9496f306/attachment-0005.html>