[Yum] once more little bug (or feature :) )

[seth vidal]

On Tue, 2002-06-18 at 22:00, Konstantin Riabitsev wrote:
> On Tue, 2002-06-18 at 20:51, seth vidal wrote:
> > so I think it should work like this:
> > 
> > yum update -> solely updates
> > yum upgrade -> updates + obsoletes, but (and this will suck for users
> > some) - all obsoletes must be confirmed by user input.
> 
> Hmm.. I'm not sure that is actually needed. Let's consider current
> problem:
> 
> red hat 7.2 has:
> zebra-0.91a-6
> gated-3.6-12
> 
> red hat 7.3 has:
> zebra-0.92a-3
> gated-3.6-14
> 
> In both cases zebra obsoletes gated and gated obsoletes zebra.
> 
> We have 7.2 installed with zebra. While we're at 7.2, we run "yum
> update" and since it's "update", it ignores all obsoletes. Then comes
> the time when we want to upgrade to 7.3. This means we go to yum.conf
> and change the repository to the 7.3 tree.
> 
> We run "yum upgrade"; yum goes out and checks if a newer package of
> zebra is available. If it is, yum doesn't check an obsolete on it, but
> simply upgrades the existing package. If, however, there is no package
> with the same name+arch in the repository, yum would check the obsoletes
> and schedule an installation of a package that obsoletes the existing
> one. To better illustrate, here's a case analysis with "OldSkool" and
> "NewSkool". NewSkool obsoletes OldSkool.
> 
> Case 1: 
>   Repository:  OldSkool-1.0, NewSkool-1.0
>   Installed:   OldSkool-1.0
>   Yum update:  do nothing
>   Yup upgrade: do nothing, since OldSkool is still in the repository.
> 
> Case 2:
>   Repository:  OldSkool-2.0, NewSkool-1.0
>   Installed:   OldSkool-1.0
>   Yum update:  install OldSkool-2.0
>   Yum upgrade: install OldSkool-2.0, since OldSkool is still in the
>                repository
> 
> Case 3:
>   Repository:  NewSkool-1.0
>   Installed:   OldSkool-1.0
>   Yum update:  do nothing, since we ignore obsoletes during yum update
>   Yum upgrade: install NewSkool-1.0, since it obsoletes OldSkool-1.0
>                and no newer OldSkool packages are available.
> 
> I think that would work just fine without the need to prompt the user.
> 


ok then that seems to make sense to me. I'm not 100% certain there isn't
a corner-case where this will break but unfortunately thats almost
impossible to tell w/o looking at every possible package <shudder>

I'll work on implementing this to deal with looping obsoletes.

this, of course, means we will have to figure out a way of getting more
special commands to the yum client w/o typing them in for nightly
updates.

I'd like to be able to tell it to perform an upgrade from time to time
to catch new stuff I might roll in. I was thinking about this and about
the wishlist todo item of have a url for global config options - it
might be cool to be able to retrieve commands via a url - ie:

yum run url://here/

then just have it perform the commands listed from the url.

then url:// could just be a cgi that dtrt - thats more of a wrapper to
yum but it could be useful I'd bet.

-sv


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
Url : http://lists.baseurl.org/pipermail/yum/attachments/20020619/bf81d1ed/attachment-0001.pgp