On Sat, Mar 28, 2015 at 11:40 PM, Peter <peter at pajamian.dhs.org> wrote: > On 03/29/2015 09:32 AM, Carl George wrote: >> https://gist.github.com/cgtx/b854281462a18007f509 >> >> If this looks familiar, it's because I used the IUS SafeRepo >> Initiative as a starting point. Please share your feedback and >> ideas. > > Sure: > >> Must not have the same name as a stock distribution package. > >> Must not automatically install, upgrade, or replace stock >> distribution packages when the repository is enabled. > > How do the above two rules affect a repository that is not enabled by > default but would end up replacing stock packages if it is enabled by > the user? As an example, this would happen with CentOS's own centosplus > repository which is included in the centos-release package. And Percona, and the mysql community repository, and RPMforge. RPMforge, I'm afraid, has become particularly perilous as it's become less maintained and components are now out of date (such as the Subversion packages I used to publish there.) Don't get me going on JPackage, which seems to be quite idle now. > What about a 3rd-party group that distributes a .repo file with one repo > that is enabled by default which is intended (by policy) to not replace > stock packages, and another that comes disabled with explicit Works for me! > instructions on how to enable it and use it (more or less) safely, the > latter being intended to replace stock packages? Especially if the packages can be roughly segregated: the maven suite, for instance, is quite large and interwoven with other Java based utilities and needs to be managed cautiously, or jpackage, which hasn't been noticeably udpated since.... Fedora 17.