update-alternatives needs verbose invalid message

[ghbittwister]

current message
admindir /var/lib/alternatives invalid
when doing
/usr/sbin/update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-7.2.2 300700

Suggest adding : command line arguments here. Example:
admindir /var/lib/alternatives invalid: --install /usr/bin/gcc gcc /usr/bin/gcc-7.2.2 300700

[lnykryn]

To be honest I don't see how this would improve things. It looks that in your case there is something wrong with /var/lib/alternatives (it is not readable or maybe it does not exist at all). So repeating command line arguments would not help.

[ghbittwister]

What you do not see is when doing package/rmp installs, I see a bunch of "admindir /var/lib/alternatives invalid" messages. I have no idea WHAT message is invalid, let alone if it is a valid message or not.

If the message is from a remove and nothing to remove, there is no reason to open a bug report.
If the message is install, then I know to open a bug report. As a system QA tester I should not have to open each invalid rpm to read post install scripts to guess which call to admindir caused the problem.

[lnykryn]

Well, it should not matter in your case, how the alternatives were called. There is something wrong with alternatives db. I think we should extend the message in a way
admindir /var/lib/alternatives invalid: "Permission denied|Does not exist|..."

[ghbittwister]

I understand what you are saying. But you are missing the point I am trying to make. A rpm has a bunch of postscript admin commands which have one or more failures. There is no way to identify which had a failure. Example: take the gcc-5.4.0-5.mga6.src.rpm for example:
postinstall scriptlet (using /bin/sh):
/usr/sbin/update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-5.4.0 300500
[ -e /usr/bin/gcc ] || /usr/sbin/update-alternatives --auto gcc
/usr/sbin/update-alternatives --install /usr/bin/gcc-ar gcc-ar /usr/bin/gcc-ar-5.4.0 300500
[ -e /usr/bin/gcc-ar ] || /usr/sbin/update-alternatives --auto gcc-ar
/usr/sbin/update-alternatives --install /usr/bin/gcc-nm gcc-nm /usr/bin/gcc-nm-5.4.0 300500
[ -e /usr/bin/gcc-nm ] || /usr/sbin/update-alternatives --auto gcc-nm
/usr/sbin/update-alternatives --install /usr/bin/gcc-ranlib gcc-ranlib /usr/bin/gcc-ranlib-5.4.0 300500
[ -e /usr/bin/gcc-ranlib ] || /usr/sbin/update-alternatives --auto gcc-ranlib
postuninstall scriptlet (using /bin/sh):
if [ ! -f /usr/bin/gcc-5.4.0 ]; then
/usr/sbin/update-alternatives --remove gcc /usr/bin/gcc-5.4.0
fi
if [ ! -f /usr/bin/gcc-ar-5.4.0 ]; then
/usr/sbin/update-alternatives --remove gcc-ar /usr/bin/gcc-ar-5.4.0
fi
if [ ! -f /usr/bin/gcc-nm-5.4.0 ]; then
/usr/sbin/update-alternatives --remove gcc-nm /usr/bin/gcc-nm-5.4.0
fi
if [ ! -f /usr/bin/gcc-ranlib-5.4.0 ]; then
/usr/sbin/update-alternatives --remove gcc-ranlib /usr/bin/gcc-ranlib-5.4.0
fi

If two or three fail during package install/update I have no idea which ones failed.

[lnykryn]

Hmmm, I see. My problem here is that I can't image a situation where this would fail only in certain cases. If there is something wrong with /var/lib/alternatives then basically every call of alternatives will fail, so a specific command should not matter.
Honestly, change you are requesting is totally simple, but my twisted developer brain still says that it does not make sense. If you give me a reproducer where one call will succeed and the second one will fail, I will do that. Otherwise, I am already writing a patch that will print "admindir /var/lib/alternatives is not writable" :-)

[ghbittwister]

Glad to hear you are a developer. Now put your package manager hat on, and a system tester gets one or more errors installing some package. As a developer/package owner would it not make the pkg manager's life easier if the bug reporter put which update-alternatives failed.

Consider this, update-alternatives --remove xxx will return a failure and as tester, I would not bother reporting an error if xxx did not exist.