status of up2date and rhn-applet

[Axel Thimm]

On Thu, Dec 01, 2005 at 07:36:53AM -0800, Jesse Keating wrote:
> On Thu, 2005-12-01 at 12:36 +0100, Axel Thimm wrote:
> > 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.
> > 
> 
> The real issue here is that the user wants one little thing from AT.
> They want to try out an experimental test module for a piece of
> hardware.  They don't want to replace many core packages.  They get
> frustrated when they want to install this little thing and they get a
> rather confusing dep list.

Same with updates-testing. If you simply activate updates-testing,
because there is a nice pacxkage update you have been waiting for,
then you either get the whole bunch, or you need to figure out the
dependencies yourself.

> Just why do you force your replacement packages on users?

Nobody forces anyone. The argument that seems to drift away is that if
you don't like a subset of a repo and use tools like apt and smart to
automatically filter out some packages, other packages will break if
depedending on functionality of the filtered out package.

So it's either dropping the repo altogether or figuring out the
(functional!)  dependencies manually. I just don't want get bug
reports, because a user filtered out the upgrade of package bar needed
for package foo.

> What is it about your replacement core packages that are so much
> better for Core users that anybody who uses any of your rpms must
> have all those replacements?[1]

It depends on the package. Some dependencies require activating more
build configure options & BuildRequires, others a newer version. There
is no general rule of thumb, and I certainly don't try to kill my time
by unneccessary work.

> It seems to me that you're just waving your hand over it and saying
> "oh they're fine... don't worry about those..."  You're saying that
> if you want to use a experimental module (and possibly remove it
> right directly) well too bad, you have to have all these packages
> too, and you have to like it.

Is that what updates-testing is saying? Show me the solution there and
I'll take it over for atrpms-testing. If you want to only test the
latest testing kernel but not gcc/whathever you will face the same
situation, either upgrade to all in updates testing, or pull down only
the package(s) you need and possibly some further dependencies found
there.

Do the same with ATrpms and any other repo, you want. You wouldn't use
apt's and smart's automated weighing alghorithms on updates-testing
for the very same reasons I recommend not to use them on anything
else.

> [1] It has been a while since I used any AT rpms.  I don't know if
> it is still the case that one AT package would mean replacement of a
> lot of Core packages anymore.  I'm just going by other people's
> emails and your responses.

Well, w/o even testing the repo and its contents how can you make a
statement on whether and which packages are unneccessary updates, and
whether or not stability of your system is at stake?
-- 
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/20051201/ea409e34/attachment.sig>