[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: status of up2date and rhn-applet



On Tue, Nov 29, 2005 at 07:50:40PM +0100, Benny Amorsen wrote:
> >>>>> "AT" == Axel Thimm <Axel Thimm 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.

No, see my other reply. If this were so, then 99.99% of all package
dependecies in the base distro are broken as well.

> 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.

I really wonder what makes accepting "package replacements" so hard,
when you accept "kernel functionality replacement". If I were to fear
about destabilisation of my system, then I would place avoiding kernel
modules at number 1.

But no, some are upset that libtool gets replaced, but they happily
effectivly replace their kernel modules. And are even (obviously)
using the testing repo from ATrpms, as the kernel modules you want are
in there.

Ergo: If you have concerns with ATrpms replacing some packages, then
you should have even more concerns with your wish for ATrpms to
replace parts of your kernel. Or if you don't have concerns with the
latter, then the former ones are certainly safer to use.

The "ATrpms replaces packages!!!" is an old, but effective FUD
mechanism to scare users off using ATrpms. Yes, there were Clone Wars
before they got on the screen.

ATrpms exists several years with a large userbase. If this were such a
bad thing to do, there would had been known breakages due to this,
right? Like any software project ATrpms is not bug free, but bugs are
not related to "package replacement".
-- 
Axel.Thimm at ATrpms.net

Attachment: pgpHQrdH6e5qw.pgp
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]