[Rpm-maint] Commit fafd8090 (Dead code removal)
Michael Schroeder
mls at suse.de
Tue Apr 13 09:02:26 UTC 2010
On Tue, Apr 13, 2010 at 09:51:12AM +0300, Panu Matilainen wrote:
> >Regarding commit fafd80901c129659d4d0c1945f5922858f410ef7, please
> >test if a refresh of a package which obsoletes itself works.
>
> Well, the commit doesn't change any behavior, it just removes dead code
> which hasn't been active in > 5 years. So if its broken, its been that way
> for a long long time :)
Yes, I just wanted to bring that topic up again ;-)
> >By "refresh" I mean the re-installation of an already installed
> >package.
> >
> >i.e. if package A contains an "Obsoletes: A", try
> >
> > rpm -i A.rpm
> > rpm -Uvv --oldpackage A.rpm
> >
> >A package refresh shouldn't run the uninstall scriplets (for
> >whatever reason).
>
> Hmm.. with current HEAD you get this:
> [root at dhcp102 rpm]# ./rpm -Uvh --oldpackage
> /home/pmatilai/rpmbuild/RPMS/noarch/obstest-self-0.1-1.noarch.rpm
> error: Failed dependencies:
> obstest-self is obsoleted by (installed) obstest-self-0.1-1.noarch
That's surprising, my guess was that addObsoleteErasures() doesn't
look for self-obsoletes and adds the installed package to the
remove list. But in that case rpmtsPrunedIterator() shouldn't
have returned the installed package.
Btw, I'm not sure if the installed obsoletes are really just matched
against the package NEVRs and not the provides. Doesn't
rpmalSatisfiesDepend() used in unsatisfiedDepend() look at the
provides?
(And why is checkInstDeps() using unsatisfiedDepend() for conflicts
and obsoletes, which also looks at other installed packages?
I don't think it should report problems installed packages have with
other installed packages. Or am I misreading the code?)
Cheers,
Michael.
--
Michael Schroeder mls at suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
More information about the Rpm-maint
mailing list