apt-rpm handles obsoletes differently?

[Panu Matilainen]

On Fri, 5 May 2006, Vincent Danen wrote:

> 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)

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.

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.

> 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 :)

 	- Panu -