Re: yum and apt differences.

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

 



On Fri, 20 Feb 2004, Eric Rostetter wrote:

> Quoting "Charles R. Anderson" <cra@xxxxxxx>:
> 
> > I brought this up at the time I packaged yum, but there was no
> > consensus other than yum should behave the same way up2date did (which
> > is why it exludes kernels by default), and root's gpg keyring
> > shouldn't be messed with automatically by the package.
> 
> Sounds like apt should follow the same rules then, no?

The matter is a bit different on RHL 7.x since there it's indeed messing 
with roots gpg keyring (doesn't have to be that way, you could just as 
well make the gpg-checker script import to alternate keyring and check 
from there), on rpm >= 4.1 the keys get imported into rpmdb.

That was a feature people wanted for fedora.us apt, if you don't like the 
auto-import of keys then either
a) make it use alternative keyring
b) expect to deal with lotsa people complaining about unknown signatures 
:)

> 
> > Does anyone use apt non-interactively, i.e. via cron?
> 
> I don't think that is relavent really.  Why would it matter?
> 
> > If not, then
> > these differences don't matter too much I guess.
> 
> Sure they do.  I install apt, run it, and it messes with my root user's
> key ring.  It doesn't even tell me what it is doing to it, just that it
> is changing it.  At least I'd like to know what it is doing, if it's
> going to do anything at all.

See above, also no reason why you couldn't make that interactive...

> 
> > I view apt as a
> > nicer user interface, more featureful sysadmin tool to be used
> > interactively, not as an autoupdate mechanism.
> 
> I don't see how that matters.  So, you say to do updates, hope you notice
> that one of the updates is a kernel update.  You don't know what that means,
> or if it will squash your custom kernel, etc.  (Does it upgrade the kernel,
> so it removes your old one?  Does it make the new kernel the default boot
> kernel?  Does it upgrade obsolete modules?) So you have no choice but to
> abort the whole thing (AFAICT) and then change the apt config files
> (hopefully you know where they are, how to change them, etc), and then
> restart the hole update.  (Or just roll the dice and see what happens)
> 
> I guess I would sum it up as:  If Red Hat didn't have enough faith in
> an automatted update of the kernel, then why should we?  If we're supposed
> to change as little as possible for compatability with previous behavior and
> to avoid surprises to the admin, then shouldn't stick with the way Red Hat
> did these kinds of things?

First people complain about apt not upgrading kernels and when it finally 
does people complain about that :) Fedoralegacy apt is yours to configure 
as you please, just ship with different defaults than fedora.us apt if 
these things bother you:
RPM::Upgrade-Virtual=false (to prevent automatic kernel "upgrades", it 
doesn't upgrade the package but installs a new one like it should)
Kernel::Set-Default=false (don't make the new kernel default)

I had a discussion about this with Seth a while ago on IRC and agreed that 
for most new(ish) users it's probably the right thing to do (upgrade 
kernel, make it default), experienced admins and such can change the 
default settings as they please (eg on server you might not want that 
automated kernel update or making it default)

	- Panu -




[Index of Archives]     [Fedora Development]     [Fedora Announce]     [Fedora Legacy Announce]     [Fedora Config]     [PAM]     [Fedora General Discussion]     [Big List of Linux Books]     [Gimp]     [Yosemite Questions]

  Powered by Linux