Samuel Sieb wrote: > It lets me know that something else was run, just like there's a line saying > that it's running a scriptlet for package whatever. As I mentioned, I would > much prefer that there was some part of that line that said what the unit is > for, but at least with that line I know that it's happening and I can check > the logs if necessary.
There is a lot that is run which is not included in the
rpm/dnf output. Including it all would be far too verbose
to be useful. Scriptlets are supposed to be silent.
>> All I see in the case of the man-db-cache-update scriptlet
>> is that the typical >/dev/null was missed when it was
>> converted to use systemd-run. The scriptlet before was:
>>
>> MAN_NO_LOCALE_WARNING=1 /usr/bin/mandb -q
>>
>> That is silent by design. The MAN_NO_LOCALE_WARNING=1 was
>
> This being silent ended up being a problem. mandb took a long time to run
> and there was no explanation on why the dnf transaction appeared to be hung
> for several minutes. It would have been good if there had been some output
> saying that mandb was being run. Sure you might be able to switch consoles
> and run "ps" if you know about that, but this would have been easier.
The problem wasn't that it was silent. It was that it was a
long(ish)-running process that was not suited to run as a
scriptlet. It's better done via cron or as it is now as a
transient systemd-run service.
Anyway, I think the current output is unintentional.
Whether the man-db packager maintainers agree or not, I
don't know. I do feel confident that this output is a
departure from how scriptlets have long behaved and it
should be more deliberately and consistently designed if
it's going to be kept.
--
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Future, n. That period of time when our affairs prosper, our friends
are true and our happieness is assured.
-- Ambrose Bierce, "The Devil's Dictionary"
signature.asc
Description: PGP signature
_______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
