[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

/sbin/install-info causing scripts to fail esp. in gcc srpms

Hello, People

I'm a System Engineer who has been quietly (re)building distributions for
many years now (since early 1990s.)

There seems to be a rare but reoccuring bug w/ install-info that seems to
occur a hugely disproportionate amount in the post/pre scripts of gcc srpms.

The earliest instance I recall was with libgcj-3.2.1-2 back in Redhat 8.0 and it is
present again in the latest devel gcc-gnat-3.4.1-7.

In gcc-gnat's case, install-info seems unable to delete gnat_ugn_unw from
/usr/share/info/dir as we see here:

/sbin/install-info --delete --info-dir=/usr/share/info /usr/share/info/gnat_ugn_unw.info.gz
install-info: warning: no entries found for /usr/share/info/gnat_ugn_unw.info.gz'; nothing deleted
FYI shell returns 0

However it does realize it is in fact there if I try to reinstall it:

/sbin/install-info --info-dir=/usr/share/info /usr/share/info/gnat_ugn_unw.info.gz
install-info: menu item `GNAT User's Guide (gnat_ugn_unw) for Native Platforms / Unix and Windows
' already exists, for file (none)'
FYI shell returns 1

The grep below confirms that the file is really still listed in the dir file.

grep -i gnat_ugn_unw /usr/share/info/dir
* GNAT User's Guide (gnat_ugn_unw) for Native Platforms / Unix and Windows

If I change gcc-gnat spec file's post gnat script to somelike like this it
fixes the dir file and avoids the problem:

%post gnat
/sbin/install-info \
  --info-dir=%{_infodir} %{_infodir}/gnat_rm.info.gz
if ! grep -q '(gnat_ugn_unw)' /usr/share/info/dir; then
  grep -v '(gnat_ugn_unw)' /usr/share/info/dir | >/tmp/infodir.$$
  mv /tmp/infodir.$$ /usr/share/info/dir
/sbin/install-info \
  --info-dir=%{_infodir} %{_infodir}/gnat_ugn_unw.info.gz || true

Any time one of these messes occurs we end up with two different version of
a given rpm in the database and are forced to remove both versions, remove
the entry which didn't get deleted properly from /usr/share/info/dir and
re-install the package.

I'm not trying to say libgcj or gcc-gnat are not important, however if this
happened with a more critical system library such as libstdc++ or glibc this
could get exceedingly ugly.

In my opinion, we really should not be failing to upgrade/install critical
tools because their info files fail to get indexed properly.

Anyone know why this keeps happening?

Could we PLEASE do something to make the failure of a /sbin/install-info
install only a warning (it is very painful to have to keep recompiling gcc
to fix this issue)?

Adding || true to the end of ALL install-info install commands (--delete
lines don't need it) in the gcc rpm seems to guarantee we will avoid this
problem. For example:
/sbin/install-info --info-dir=/usr/share/info /usr/share/info/gnat_ugn_unw.info.gz || true

Could someone please do this in the devel gcc spec for now at least until
the real problem is found?


---------------------"Happiness is understanding."----------------------
Robert Hardy, B.Eng Computer Systems                  C.E.O. Webcon Inc.
rhardy <at> webcon <dot> ca    GPG Key available          (613) 276-7327

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]