Hi,

On Wed, Jan 04, 2006 at 08:57:06PM +0100, Jaroslaw Polok wrote:
> > (Most) ATrpms libraries have been repackaged in such a way that
> > different major lib versions can coexist, so when a repo upgrades
> > libfoo from libfoo.so.2 to libfoo.so.3 no conflicts arise. That has
> > been quite some help in improving interrepo compatibility.
> 
> That's what I thought ... thanks for confirmation...
> 
> > Bottom line: If there appear any conflicts (not only between the two
> > mentioned repos, but in general), just let both sides know.
> 
> Since you ask ;-):
> 
> I've got a question about ATrpms:
> 
> Why are you providing also updates of packages which are
> in the base distribution (either FC or RH) ?:
> 
> for example:
> 
> zlib ?
> xorg-x11 ?
> libtool ?
> (... etc ...)

It depends on the package. IIRC correctly: zlib for fixing some ugly
CANs, xorg-x11 for EPIA support, libtool as a build dep for some
x86_64 bugs in other packages.

> changelog of above does not give any hint why have you
> rebuilt these ?

They should contain items like CANs, but they don't contain items like
"package foo, bar and now foobar require a newer libtool".

> Do these differ from ones released by RH/FC ?

Also depends on a package. Some are required backports, others have
bug fixes and others again more BuildRequires.

> Giving the unablity of yum to setup repository preference

In fact there are ways to have yum do what you want, at least newer
yum versions which allow plugins.

> and at the same time importance of strict RHEL compatibility at
> which many of Scientific Linux users aim ...

Oh, ATrpms is strict RHEL4 compatible, I can guarantee that, including
the packages being replaced. :)

> This could be potentially a problem .. I believe ?

Potentially, but several years of ATrpms and even some more before
ATrpms have shown that the typical issues are to be expected
elsewhere. On the contrary, fixes in rpm, glibc and even openssh had
been propagated in 3rd party repos before the vendor had time to fix
them (or never did like for rpm).

Perhaps that's to be expected. Usually the packages that are replaced
are already of higher maturity, so fixing or extending them invites
less trouble than creating new packages from scratch.
-- 
Axel.Thimm at ATrpms.net