[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rpmorg-list
Subject:    Is there a way to turn off %pretrans?
From:       thierry.vignaud () gmail ! com (Thierry Vignaud)
Date:       2016-04-05 16:17:14
Message-ID: CAONrEta6CDsX2G3LxrENb8ET4PWh0Dwoj4Ytd-PJCX4ENTDxxw () mail ! gmail ! com
[Download RAW message or body]

On 5 April 2016 at 11:06, Panu Matilainen <pmatilai at laiskiainen.org> wrote:
> No amount of ordering can satisfy Requires(pretrans) dependencies that are
> not already installed. By definition, pretrans scriptlets run before the
> transaction has started, so Requires(pretrans) provider has to be already
> installed, it cannot come from the transaction that is about to start.
>
> Newer rpm can correctly express this: a pretrans dependency on a
> non-installed package will simply always fail on dependency check. Older
> versions just ignore the unsatisfiable dependency.
>
> In practise this means that something like "Requires(pretrans): /bin/sh" can
> only ever work on an already installed system (including system upgrade),
> but never on a fresh installation. Which of course is rather useless, and
> which is why all %pretrans scriptlets have to be written using the embedded
> Lua interpreter (ie %pretrans -p <lua>) in practise.

That is in the yum world :-)
In the urpmi world, packages are installed by transaction batches of 8
by default (or more if deps force to aggregate more pkgs), so only
packages in first transaction have to rely on a lua scriptlet
(providing bash is installed in the first transaction that is, which
it is)
Other packages can (and some happily do) use %pretrans written with sh
Typically urpmi first installs the following:
bash, dash-static, filesystem, glibc, grep, lib64ncurses6, lib64pcre1,
libgcc1, libstdc++6, ncurses, run-parts, setup,
Thus packages in next transactions can use such pretrans

Of course, on RHEL this don't apply and as I said the scriptlet must
just be dropped here

[prev in list] [next in list] [prev in thread] [next in thread]