On 08/14/2012 10:30 PM, Chuck Anderson wrote:
I ran into a comedy of errors today after I did a new F17 installation
yesterday. Here are a couple:
https://bugzilla.redhat.com/show_bug.cgi?id=848148
Error in PREIN scriptlet in rpm package wireshark-1.6.9-1.fc17.x86_64
(and why does yum still let the transaction succeed, creating problems
in the RPMDB, broken dependencies?)
This would be one for the FAQ...
Rpm transactions are not ACID, nothing of the sort. Rpm only guarantees
that a transaction does not start if pre-determined problems exist -
such as missing dependencies or insufficient disk-space. Once the
transaction train is off the platform, it brakes for nobody.
Basically, just aborting a transaction-in-progress on scriptlet errors
and such is just as likely to create problems (including broken
dependencies) as is limping on. What seems obvious with a transaction of
2-3 simple packages with a nice and clean C -> B -> A dependency chain
is much less so when you have tens or hundreds of inter-dependent
packages with myriad dependency loops amongst them, some with %pretrans
scriptlets that have already executed, modifying the system in ways that
cannot be rolled back. Etc.
See http://rpm.org/ticket/805: it could be made a bit smarter, but as
the general case is essentially unsolvable this area hasn't seen much
effort.
https://bugzilla.redhat.com/show_bug.cgi?id=845671
"Directory '/var/run/screen' must have mode 777." when opening screen
(and why does systemd-tmpfiles completely fail to start when there is
a missing group--it should fail gracefully, allowing the other
tmpfiles stuff to run and the service as a whole to run)
Both of these are traceable to missing entries in /etc/group. In the
former cae, there is an explicit "Error in PREIN" script during
instalation. In the latter case, there is only a warning and
installation proceeds:
Running Transaction
Installing : screen-4.1.0-0.9.20120314git3c2946.fc17.x86_64 1/1
warning: group screen does not exist - using root
warning: group screen does not exist - using root
So what is going on with %pre not running groupadd properly? Are there
any known issues in this area?
From rpm's POV there are two main reasons for correct-looking scripts
failing, and both are packaging issues:
1) missing dependencies on items the scriptlet needs
2) dependency loops preventing correct ordering
This case appears to be selinux-related, and there's not a whole lot rpm
can do about that.
- Panu -
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
