Hi,

On Wed, Jan 04, 2006 at 10:14:30PM +0100, Jaroslaw Polok wrote:
> >>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.
> 
> Right, as Troy mentioned in this thread the yum protectbase plugin
> shall do there ... [there is still a small BUT there: if somebody
> wants to use yumex ... that one disables ALL yum plugins ... just
> 'discovered it ...]

For several reasons I personally suggest people not using ATrpms at
all when they are thinking of starting to filter out part of the
repo. The repo is not designed to used that way. If a package foo has
been extended from the vendors' version to allow building of bar, the
only allowing bar to be installed will break the setup. I had many
reports that are due to filtering out some required packages, e.g. the
vendor not-replaced package was still in place.

The reasons sometimes mentioned for not trusting package replacements
are security and destabilization. But then the same apply for the rest
of the repo as well.

> >>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. :)
> 
> Ooops, lack of precision after 2 weeks laziness , sorry, Of course
> it is, what I'm (again potentially ;-)) afraid of is that:
> 
> sbdy builds a package depending on libfoo.Y where libfoo.Y comes
> from ATrpms (while original RHEL provides libfoo.X) ..
> such package will not be compatible with plain RHEL anymore ..

Of course. Same thing applies if the build's configure step
implicitely senses some other libraries present and builds against
them. So again the issue in not specific to replacements.

> [actually similar situation happened to us in the past when I've
> rebuilt some RHEL srpms for SL while having updated - for XFS -
> libattr/libacl on my built system .. resulted in update problems for
> users ..]

That's a perpertual issue, just like building apt for RH7.3 & updates
which included a glibc update with symbols, and thus could not be
installed on RH7.3 w/o updates. So a chicken and egg was created back
then.

For this reason ATrpms uses several chroots for building
packages. E.g. vendor w/o updates, vendor w/ updates, vendor & ATrpms
etc.

> > 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.
> 
> I personally have no problem with that (and fully agree that some
> problems really SHALL be fixed): but it would be nice to make it
> clear to all repository users that the repository contains packages
> replacing vendor ones not only add-ons.
> 
> I believe that users think that aditional repositories
> are just that: additional packages -
> If I'm not mistaken ATrpms is the only one for RHEL/FC4
> which provides more then just add-ons

You are. There is no 3rd party repo w/o replacements. :)

Only Fedora Extras has nowadays not replacements for Fedora Core. All
the rest, be it ATrpms, livna, dag, kde-redhat, planetccrma do carry
such. Even Fedora Extras did when it was called fedora.us (e.g. rpm
and shadow-utils).
-- 
Axel.Thimm at ATrpms.net