On Thu, May 19, 2011 at 6:05 AM, Dag Wieers <[log in to unmask]> wrote:
> On Wed, 18 May 2011, Akemi Yagi wrote:
>
>> On Wed, May 18, 2011 at 8:53 AM, Orion Poplawski <[log in to unmask]>
>> 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.

Hi, Dag!! Nice to see you over here.

There's also stil the ongoing boobytrap for RHEL and SL before version
6.x: They built, and provided, and installed, both i386 and x86_64
versions in the main x86_64 repository of many packages such as
Subversion. So does EPEL. RPMforge does not, and in fact, *building*
Subversion for i386 under x86_64 architecutre was a real pain in the
neck: I threw in the towel on it.

The result was that upgrading Subversion for x86_64 from RPMforge
got... tricky if you didn't manually rip out the i386 packages before
updating to RPMforge's version (of which I posted .spec files for a
few releases). RHEL and SL 6 now install only the "best" architectural
fit, by default, which was an excellent move and avoids this issue.


> 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.

Subversion is one of these. The continuing updates from RPMforge are
welcome, RHEL's upstream version is going to continue to lag,
especially after Subversion 1.7 comes out.

>  - 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.

And this sort of thing is why RPMforge is so respected. When an issue
pops up, it gets fixed *FAST*.