--=-9rk5W9c+LVf/9gWFMQPk Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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: > >=20 > > yum update -> solely updates > > yum upgrade -> updates + obsoletes, but (and this will suck for users > > some) - all obsoletes must be confirmed by user input. >=20 > Hmm.. I'm not sure that is actually needed. Let's consider current > problem: >=20 > red hat 7.2 has: > zebra-0.91a-6 > gated-3.6-12 >=20 > red hat 7.3 has: > zebra-0.92a-3 > gated-3.6-14 >=20 > In both cases zebra obsoletes gated and gated obsoletes zebra. >=20 > 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. >=20 > 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. >=20 > Case 1:=20 > 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. >=20 > 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 >=20 > 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. >=20 > I think that would work just fine without the need to prompt the user. >=20 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 --=-9rk5W9c+LVf/9gWFMQPk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9EBOq1Aj3x2mIbMcRAkhFAKCQ0MQlemDrHxPR1X1wmVhUpUvtRwCdFh0U xlR0l2KDDw0qvVDDofQHDRk= =WDXI -----END PGP SIGNATURE----- --=-9rk5W9c+LVf/9gWFMQPk--
