Shaping repos according to terminology (was: Choosing YUM Repositories)

Axel Thimm Axel.Thimm at ATrpms.net
Tue Aug 9 20:59:43 UTC 2005


On Tue, Aug 09, 2005 at 01:56:49PM -0500, Les Mikesell wrote:
> On Tue, 2005-08-09 at 12:31, Axel Thimm wrote:
> 
> > And while you could argue that although most repo maintainers consider
> > this distinction irrelevant, they could nevertheless offer this split
> > view, there are valid reasons for not doing so, see other replies in
> > this thread explaining interdependency issues of non-replacement and
> > replacement packages.
> 
> What currently valid reason is there for breaking the ability
> to get the stock distribution updates? Can't everything that
> has to be recompiled with different options also be renamed or
> relocated?

No, certainly not everything. And if you relocate all to /usr/local
what benefits will you have???

You would either have /usr/local before /usr, so it's the same like
unistalling the old package, or after, which is the same like not
installing the new one ...

> > For having users decide their experimentation level themselves, some
> > repos have stability split repos, which is a far more useful thing to
> > do.
> 
> It doesn't make much sense to me to call a repo stable if it is
> still allowed to contain rpms that conflict with the distribution's
> own.

Not if you are defining "updates"/"enhances" equal to "conflicts". In
this manner even updates-released is not stable, as it "conflicts"
core packages ... :)

Almost all my setups are Fedora Core/RHEL full installs with ATrpms
upon that (and more). Nothing _conflicts_, and it *is* _stable_.

Yes, there can be bugs in repos and the vendor distribution, which for
third party repos usually are in the non-replacement parts, and for
the vendor in the replaced ones ...
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20050809/f1638e69/attachment-0001.sig>


More information about the fedora-list mailing list