On Jul 19, 2013, at 11:32 AM, Arkadiusz Miśkiewicz wrote:
> On Friday 19 of July 2013, Jeffrey Johnson wrote:
>
>> Meanwhile why not just disable the buggy scriptlet
>> using a rpm cli option and manually erase and reinstall?
>
> You need to know that's the correct way to dealing with this situation. Users
> think it's some kind of bug.
>
Busted RPM package because of lack of QA is hardly a new problem.
In fact pain is an effective learning experience ;-)
Meanwhile its likely time to insturment a means to
disable other package scripts automatically in RPM.
The effect would be the same as if the new user had typed
the already implemented scriptlet disabler option on the cli
or through your depsolver du jour.
The first (and easier part) of the implementation would be
to change the disabler scripts to be per-package rather
than global for the entire set of packages.
The second (and slightly trickier) implementation would be
to establish a scoping across the set of packages currently
in the transaction that were already installed. This might
be done with a namespace class using EVR comparison.
An example:
Let's say a %preun script in the package foo-1:2-3 is busted, thereby
preventing upgrade and erasing.
The current implementation would add --nopreun to erase the package
rpm -e --nopreun foo-2-3
without executing the %preun script.
This might be mapped onto some dependency string syntax like (I will use a
Provides:
example *shrug*)
Provides: nopreun(foo) = 1:2-3
which would disable (like --nopreun on the cli, but limited to the set of
(usually erased) packages that match the EVR comparison in the current
transaction.
Make sense? Its not hard to code something like this in RPM5 code,
and the "legacy compatible" issues of adding a namespace string in Provides:
are likely vanishingly small.
>> KISS is always best.
>
> KISS would be if this work without user having to ask on mailing lists or
> google solution.
>
KISS (and pain as a teaching tool ;-) in packaging doesn't address the
root cause
Ineffective distro QA which failed to detect an obvious scripting flaw.
(aside)
And -- if I attempt the implementation I just outlined -- I am forced to
"support" and diagnose and listen to complaints on mailing lists and
explain why flawed hack-o-rounds found on GOOG (like "Reinstall!", sigh)
aren't the correct/best solution.
E.g. I think most RPM users have no idea that --nopreun exists and why
--nopreun is preferred to --noscripts in spite of the fact that there is a
solution
available for buggy rpm scriptlets for more than a decade.
Please post this message into a blueprint against RPM at
https://launchpad.net/rpm
if you want to see some mechanism like above implemented.
73 de Jeff
_______________________________________________
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
