On Fri, 2009-01-23 at 14:55 +0100, Robert Scheck wrote: > On Fri, 23 Jan 2009, Rahul Sundaram wrote: > > It would be good to document best practises when spec files are reused > > in RHEL as is going to happen repeatedly so that both sides understand > > what is to be done. Someone interested in not seeing things like this > > should volunteer. > > Best practise is, if packagers would know, how packaging and ENVRA works - > which seems not known to all packagers (independent whether Fedora or Red > Hat at this case). > > My previous e-mail explains correct, why not bumping release of ENVRA is > broken in such a case (which also would automagically cause %changelog to > get silent rpmlint) and why it has to be fixed by Red Hat and why we at > EPEL can't fix or solve it completely. So if somebody does not understand > that, he/she shouldn't be a RPM packager at all, sorry.
I agree completely. What should be done now is an increase of the release version in RHEL ( / CentOS), in order to get all installations from EPEL to update to the Red Hat version. What is a completely different question, however, is what to do with the packages in EPEL. If the release in RHEL is incremented, and the package is updated in EPEL afterwards to a higher EVR, the RHEL version will be replaced with the EPEL version. As a EPEL package maintainer, branching versions for different RHEL releases (Updates) would be a humongous task, as some components need special tweaks to work. Also, running an old release poses a security threat. Overlapping packages should be removed from EPEL, once a higher EVR is available in RHEL. We shouldn't even think about people who don't want to update to the newest RHEL release; if they need something from EPEL, they can compile the srpms theirself. -- Jussi Lehtola <[email protected]> _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
