apt-rpm handles obsoletes differently?

[Vincent Danen]

* Panu Matilainen <pmatilai at laiskiainen.org> [2006-05-05 14:13:56 -0700]:

> > Got a quick question here. I've built apt and have setup a repository 
> > for Annvix.  So far so good.  Got my sources setup and everything. 
> > With everything up to date, when I run "apt-get dist-upgrade" I'm seeing 
> > this:
> >
> > [root at build apt]# apt-get dist-upgrade
> > Reading Package Lists... 33%
> > Reading Package Lists... Done
> > Building Dependency Tree... Done
> > Calculating Upgrade... Done
> > The following packages will be REPLACED:
> >  exim (by postfix)
> > The following NEW packages will be installed:
> >  postfix
> >  0 upgraded, 1 newly installed, 1 replaced, 0 removed and 0 not upgraded.
> >
> > Which is odd because it shouldn't (ie. urpmi --auto-select does not try
> > to do this).  So, postfix is now installed instead of exim and then I
> > get:
> >
> > [root at build apt]# apt-get dist-upgrade
> > Reading Package Lists... Done
> > Building Dependency Tree... Done
> > Calculating Upgrade... Done
> > The following packages will be REPLACED:
> >  postfix (by exim)
> > The following NEW packages will be installed:
> >  exim
> >  0 upgraded, 1 newly installed, 1 replaced, 0 removed and 0 not upgraded.
> >
> >
> > And this will keep happening.  Now, I suspect this is due to how
> > obsoletes is being handled, and maybe this isn't the best behaviour for
> > how to handle obsoletes, but exim obsoletes postfix and postfix
> > obsoletes exim.  The rationale behind this is so that if someone does a
> > "urpmi exim" then postfix will be uninstalled, and the opposite if they
> > "urpmi postfix" and exim is installed (it will get removed).
> >
> > Now, maybe urpmi handles this differently than apt-rpm does (well, it
> > obviously does).  I suppose this could be solved by using conflicts
> > instead of using obsoletes.
> >
> > Is that the problem?  With the obsoletes tag?
> 
> Yes, that's called an obsoletes loop, a condition which is best avoided by 
> not creating them in the first place :) The behavior you're seeing is in 
> no way specific to apt, anything that considers obsoletes in the upgrade 
> operation will behave this way. It's quite possible that urpmi doesn't 
> consider obsoletes unless specifically told to, much like apt and yum have 
> (see below)

Well, I wouldn't use it if I thought it was a problem... =)  Like I
said, I've never seen this happen with urpmi, which is why I was asking.

> Using conflicts would behave the way you want it to, eg the packages are 
> only replaced if the user explicitly asks to install a conflicting 
> package, without having the side-effect of fully processed (including 
> obsoletes consideration) upgrade you're seeing.

Ok, then I'll fix my packages to use conflicts as opposed to obsoletes.

> OTOH, you could just use "apt-get upgrade" instead of "dist-upgrade" and 
> the problem will go away.
> 
> The main difference between those is that dist-upgrade takes obsoletes 
> into account, upgrade doesn't. So if your packages never get renamed 
> within a stable release, "upgrade" is the right thing to do and that's how 
> it's originally meant to be used (in Debian with it's packaging policies 
> applied): "apt-get upgrade" to pull in updates for a given distribution, 
> "dist-upgrade" is only to be used (and required) for upgrading from one 
> distribution version to another - hence the name.

Ahhh... I see.  I've always used dist-upgrade with apt (well, with fink
anyways).  So I wasn't aware there was a difference.  I think I'll want
to use conflicts in this case anyways because Annvix absolutely needs to
be 100% remotely upgradeable, and that would include package renames,
changes, etc.  So dist-upgrade would definitely be useful there.

> > I see that Mandriva has included a certain patch that "enhances the 
> > sorting by taking Obsoletes into account".  While I used Mandriva's spec 
> > as a starter, I dropped all of their patches (I prefer not to patch the 
> > crap out of stuff that I maintain).  The patch is small:
> >
> > [vdanen at build p]$ cat
> > apt-0.3.19cnc53-stelian-apt-pkg-algorithms-scores.patch
> > --- apt-0.5.4cnc9/apt-pkg/algorithms.cc.orig    Wed Nov 21 17:45:34 2001
> > +++ apt-0.5.4cnc9/apt-pkg/algorithms.cc Wed Nov 21 17:46:12 2001
> > @@ -566,6 +566,8 @@
> >       {
> >         if (D->Type == pkgCache::Dep::Depends || D->Type == pkgCache::Dep::PreDepends)
> > 	     Scores[D.TargetPkg()->ID]++;
> > +	 if (D->Type == pkgCache::Dep::Obsoletes)
> > +           Scores[I->ID]++;
> >       }
> >    }
> >
> > I'm not sure if I should stick this patch in and if it would solve the
> > problem or not (because I'm not sure how urpmi will handle changing the
> > obsoletes to conflicts... I suspect it should be ok, but....)
> 
> That patch has to do with some corner cases where dist-upgrade wouldn't 
> obsolete a package even though it basically should, so it's pretty much 
> the opposite of what you're looking after I think :)

Then I'm not applying the patch.  Thanks very much for the info, it's
been very helpful.

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}
Wasting time like it was free...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://lists.laiskiainen.org/pipermail/apt-rpm-laiskiainen.org/attachments/20060506/62992ed8/attachment-0003.pgp>