On Wed, 18 May 2011, Akemi Yagi wrote:
On Wed, May 18, 2011 at 8:53 AM, Orion Poplawski <or...@cora.nwra.com> wrote:
RPMforge now offers two repos - [rpmforge] and [rpmforge-extras].
Packages in [rpmforge] will not have conflict with the distro ones
whereas those in [rpmforge-extras] may overwrite distro files.
AH yes, forgot about that. I guess the packages it is wanting to replace on
my machine mostly come from EPEL, not the SL repositories.
But there is one:
# yum list environment-modules
Loaded plugins: downloadonly
Installed Packages
environment-modules.x86_64 3.2.7b-6.el6
@anaconda-ScientificLinux-201102250955.x86_64
Available Packages
environment-modules.x86_64 3.2.8a-1.el6.rf rpmforge
That one must have been missed. I will let Dag know. Thanks for reporting.
Yes, thanks for reporting !
I fixed it yesterday by moving this package to RPMforge-extras. When we
started building RHEL6 packages last year, we did a large effort to find
those duplicate packages, also for older distributions. The
environment-modules RPM is a newly introduced package (I presume for RHEL5
only) and we obviously did not verify if it was already in RHEL6.
There's more than one issue here:
- if a package is introduced for RHEL5, we need to check if it is needed
for RHEL6 and if there's a need to have a different version there.
- we should avoid releasing a newer package in RHEL5 than is available in
upstream RHEL6. It's often better to backport the RHEL6 package to
RHEL5.
- we need a (preferably) automated check to avoid this in the future. It
would be nice if the packager could easily check before doing any
effort at all, but as a last resort the buildsystem should refuse by
default. (It's easier to automate on the buildsystem side as a DAR
plugin, even when it's still bash :-/)
So I am sorry for this mishap, I hope we can avoid it in the future.
--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, i...@dagit.net, http://dagit.net/
[Any errors in spelling, tact or fact are transmission errors]
