status of up2date and rhn-applet

[Benny Amorsen]

>>>>> "AT" == Axel Thimm <Axel.Thimm at ATrpms.net> writes:

AT> Maybe it's better to avoid atrpms at all then, as its bar will
AT> probably assume that you are using foo from the same source?
AT> Perhaps foo in core is being replaced just to add the
AT> functionality that bar needs?

Possibly. In  my case I need  a few kernel modules  (ipw2200 for one),
and I certainly don't want all  the rest that atrpms tries to replace.
Anyway, package  dependencies are supposed to handle  the issue you're
describing. If not, the package dependencies are wrong.

AT> It isn't as black or white as it seems. I've had enough bug
AT> reports on using apt and smart with priorities/weights to strongly
AT> advise against their use (not apt/smart's, but their weighing
AT> mechanisms).

AT> And if you don't trust repo X to replace package Y, then why trust
AT> it to offer package Z? Better drop repo X, if you feel
AT> uncomfortable.

I would drop atrpms in an instant if anyone else provided those kernel
modules. However, noone else does. Atrpms is only usable for me with a
hefty exclude= line, and I'm seriously considering switching to
include=. However, that would mean never again being able to check
with yum whether atrpms provides a certain package.

Perhaps the real solution is an option to let yum list ignore exlude= and
include=.


/Benny