FC5 and Yum Plugins

[Axel Thimm]

On Thu, Dec 29, 2005 at 03:28:34PM -0500, Jeff Spaleta wrote:
> I think protectbase by default is a particularly bad idea for a
> number of reasons. But if i understand the original poster
> correctly, the problem he wants solved is a way to easily update
> packages in a way that recognizes from where installed packages were
> originally installed from after selectively install packages from a
> number of different vendors.  I don't see a good solution to this
> problem since the rpmdb doesn't keep track of this sort of
> information. The closest thing that can be used to aid this sort of
> update is gpg signatures.

I agree, this is a different problem at all. But even then I would
reconsider. Assume package foo exiting at ATrpms at FC<N> time, and
then it makes it into FC<N+1> core. You wouldn't want to exclude the
upgrade path to another repo. Also some packages may be dropped by FC
like pine was, and it may reappear in another repo. Again, you'd like
to have upgrade paths not accidentially broken due to vendor/origin
lock mechanisms.

I think these idioms are trying to cure something at the wrong
end. I'd ask the following:

o What needs to be fixed?
o Is it really broken (how many reports have there been on this
  causing a real issue)?
o Can't it be fixed at the root instead of juggling with preferences,
  weighing, scoring, repo/disto/origin locking and the same?

That's certainly something many people see differently and that must
be taken into account. There are also different roles. The sysadmin
guy will need a stable repo which guarantees non-breakage (and he will
probably not use FC but RHEL and clones, but anyway). The desktop
homeuser guy will be more open to less tested packages and more
functionality and so on.

I think this is best served in a stability graded repo. E.g. ATrpms
has stable, testing and bleeding (it used to have 5 classifications!),
kde-redhat has similar staging, and most other repos have a two
classed stability categorization by now. Using these stability grading
makes it easy to have fast QA on packages (they enter bleeding, get
promoted to testing and later stable, similar to rawhide ->
updates-testing -> updates QA, only that it happens on the same
distribution level)
-- 
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-devel-list/attachments/20051229/3beb23e4/attachment.sig>