Fwd: Re: rpm - problems with pre and postun scripts with multiple packages

[Jakub Bogusz]

Poszło też na rpm-list, więc pozwolę sobie zacytować w całości:

----- Forwarded message from Jeff Johnson -----

On Fri, May 16, 2003 at 01:00:19AM +0200, Jakub Bogusz wrote:
> Hello,
> 
> We (PLD) have found two problems with installing/upgrading/uninstalling
> of multiple packages in single rpm run (tested with rpm 4.0.x, 4.1 and
> testing 4.2 snap).
> 
> 
> The first is connected with %pre script.
> If %pre script fails (exits with non-0 code), package is not installed.
> And it's OK.
> But when multiple packages are installed/upgraded in single run with some
> of them depending on some of them (let it be package A), and %pre script
> of A fails, package A is not installed/upgraded, but all packages
> depending on package A (let they be A1, A2) _are_ installed/upgraded
> (with unmet dependencies).
> This problem can cause further problems with %pre/%post scripts from
> packages depending on A, installing daemons which can't be run because
> of too old libraries, installing plugins for new version of library
> while the old is still installed etc.
> 
> So - shouldn't all packages, depending on package whose installation
> failed, be removed from install/upgrade queue?
> 
> Splitting install/upgrade to one package per rpm run is not always an
> option - cannot be used something that requires A1 is already installed.
> Another workaround could be to check in every %pre if the most
> important package dependencies are met... but isn't it rpm's job?
> 
> 
> The second issue is connected with %postun script and Requires(postun)
> dependencies. Requires(postun) is checked correctly whe single packages
> are uninstalled/upgraded.
> But when multiple packages are uninstalled and one of them has the other
> in Requires(postun), it seems that rpm still uninstall these packages in
> the order taken from command line, regardless of this Requires(postun) -
> most likely leading to %postun script failure.
> 

Yup. Failures in %pre have always been treated differently, and rpm has
never done erasure ordering.

> 
> I think that these cases are not correct behaviour and should be
> fixed... Do you agree?

Agreed behavior is surprisingly weird and undesireable (note that I
did not say incorrect, there's basically only one behavior that has
ever been implemented).

"fixed" presumes that a test case can be written for the new behavior.
Getting the desired behavior defined is essential to getting an
implementation.

What's gonna be difficult is dealing with installers that rely on the
"weird" behavior.

The %pre handling is the simpler problem. Yawn, assume a fix.

> Could you fix it yourself or maybe we should try to prepare some patch
> first?

The first step to "fix" erasure ordering is to change the data structure
used to store added packages while installing.

(aside) Ironically, the reason I haven't done this already is because I
know that PLD (Conectiva?) uses the suggestions returned from rpmtsCheck()
nee rpmdepcheck().

If PLD is ready to use the callback in rpmtsCheck(), then I'll rework
the rather complicated added/available package list API and reimplement
the same data on a persistent backing store using Berkeley DB.

Once that work is done, then both ordering and dependency checks can/should
be done incrementally, as a side effect of adding a package, with
the current state of both dependency checks and ordering always
available.

I've already warned anaconda/up2date developers, they are mostly off of
the available package mechanism, or at least sufficiently so that
I can start reworking rpmal.c to use Berkeley DB.

Are there any other users of the available package list out there?

Speak now, please, I'm about to start ripping code ;-)

----- End forwarded message -----

Nie bardzo wiem, o co chodzi z rpmtsCheck() - o poldka/apta/wucha?

W poldku znalazłem wywołanie takiej funkcji, ale tylko przy instalacji,
a nie usuwaniu.
Zresztą nawet jeśli poldek jest dostępny, często usuwam pakiety gołym
rpm-em.


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/