9:35 a.m.
Hi,
Quote (old joke):
Pessimist: It is bad. It is really bad. It is so bad that it cannot be
worse!!! :((
Optimist: No, you are wrong .. It can be worse :)))
Today early morning I've started upgrade of my laptop with Fedora rawhide
just by execute "dnf upgrade" and approve manually list packages to
upgrade. On the list was only 106 packages and between them 48 texlive
packages (don't ask me why exactly only 48 from all more than 5k available).
After start upgrade process I went on long meeting which took me almost 4h.
What was my surprise after I've came back to my desk that upgrade still is
not finished!!! laptop fun is loud like a crazy and keyboard almost been
glowing because it was so hot .. 8-O
Few seconds to diagnose issue and I found that everything is stuck in
execution of:
root 25803 0.4 0.0 120140 3236 pts/1 S+ 11:23 0:30 /bin/sh
/var/tmp/rpm-tmp.zx4oQi 0 0
Content of this file:
--
while read file; do
shortfile=`basename $file`
if `echo $shortfile | grep -Eq
'allrunes.map|arabtex.map|arss.map|artm.map|bbold.map|cbgreek-full.map|ccpl.map|cmextra.map|cmll.map|cm.map|cm-super-t1.map|cm-super-t2a.map|cm-super-t2b.map|cm-super-t2c.map|cm-super-ts1.map|cm-super-x2.map|cmtext-bsr-interpolated.map|cyrillic.map|dvng.map|esint.map|ethiop.map|eurosym.map|hfbright.map|iby.map|latxfont.map|lxfonts.map|manfnt.map|mflogo.map|mongolian.map|musix.map|pigpen.map|plother.map|pltext.map|rsfs.map|semaf.map|stmaryrd.map|symbols.map|tipa.map|trajan.map|vnrother.map|vnrtext.map|wasy.map|xypic.map|yhmath.map'`;
then
/usr/bin/updmap-sys --nomkmap --enable MultiMap=$shortfile
/dev/null 2>&1
else
/usr/bin/updmap-sys --nomkmap --enable Map=$shortfile >
/dev/null 2>&1
fi
done
/usr/bin/updmap-sys --quiet --nomkmap &> /dev/null
--
After downloading *2GB src.rpm!!!* which contains *7325 source files!!!!
=8-O*
I found that this script is executed because in spec file is:
--
%transfiletriggerin kpathsea -- %{_texdir}/texmf-dist/fonts/map/
while read file; do
shortfile=`basename $file`
if `echo $shortfile | grep -Eq
'allrunes.map|arabtex.map|arss.map|artm.map|bbold.map|cbgreek-full.map|ccpl.map|cmextra.map|cmll.map|cm.map|cm-super-t1.map|cm-sup
er-t2a.map|cm-super-t2b.map|cm-super-t2c.map|cm-super-ts1.map|cm-super-x2.map|cmtext-bsr-interpolated.map|cyrillic.map|dvng.map|esint.map|ethiop.map|eurosym.map|hfbright
.map|iby.map|latxfont.map|lxfonts.map|manfnt.map|mflogo.map|mongolian.map|musix.map|pigpen.map|plother.map|pltext.map|rsfs.map|semaf.map|stmaryrd.map|symbols.map|
tipa.ma
p|trajan.map|vnrother.map|vnrtext.map|wasy.map|xypic.map|yhmath.map'`; then
%{_bindir}/updmap-sys --nomkmap --enable
MultiMap=$shortfile /dev/null 2>&1
else
%{_bindir}/updmap-sys --nomkmap --enable Map=$shortfile >
/dev/null 2>&1
fi
done
%{_bindir}/updmap-sys --quiet --nomkmap &> /dev/null
%transfiletriggerpostun kpathsea -- %{_texdir}/texmf-dist/fonts/map/
while read file; do
shortfile=`basename $file`
if `echo $shortfile | grep -Eq
'allrunes.map|arabtex.map|arss.map|artm.map|bbold.map|cbgreek-full.map|ccpl.map|cmextra.map|cmll.map|cm.map|cm-super-t1.map|cm-sup
er-t2a.map|cm-super-t2b.map|cm-super-t2c.map|cm-super-ts1.map|cm-super-x2.map|cmtext-bsr-interpolated.map|cyrillic.map|dvng.map|esint.map|ethiop.map|eurosym.map|hfbright
.map|iby.map|latxfont.map|lxfonts.map|manfnt.map|mflogo.map|mongolian.map|musix.map|pigpen.map|plother.map|pltext.map|rsfs.map|semaf.map|stmaryrd.map|symbols.map|
tipa.ma
p|trajan.map|vnrother.map|vnrtext.map|wasy.map|xypic.map|yhmath.map'`; then
%{_bindir}/updmap-sys --nomkmap --disable
MultiMap=$shortfile /dev/null 2>&1
else
%{_bindir}/updmap-sys --nomkmap --disable Map=$shortfile >
/dev/null 2>&1
fi
done
%{_bindir}/updmap-sys --quiet --nomkmap &> /dev/null
--
It may look elegant because whatever will be updated in
%{_texdir}/texmf-dist/fonts/map/ some <censored> update operations will be
fired.
"Problem" only is that above triggers will be executed so many times as
number of packages updating/installing anything in the fonts map directory.
Second issue is this script reads files list from stdin.
From http://www.rpm.org/wiki/FileTriggers
"This file trigger will execute /usr/bin/ldconfig right after installation
of a package that contains a file having a path starting with /usr/lib or
/lib. The file trigger will be executed just once for one package no matter
how many files in package starts with /usr/lib or /lib. *But all file names
starting with** /usr/lib or /lib **will be passed to standard input of
trigger script so that you can do some filtering inside of your script*:
%filetriggerin -- /usr/lib
grep "foo" && /usr/sbin/ldconfig
"
In other words updmap-sys will be executed so many times as *number of
packages multiplied by as many files or directories in fonts map tree all
those packages contains.*
*I'm not sure is it proper word but as long as I'm already almost 9 years
in UK I'm almost sure that at least some locals may call this just ..
BLLOCKS.*
Each time updmap-sys executions takes up to 1-2 seconds and does nothing
because nothing needs to be updated because whatever was to update was
updated in first cycle of this loop.
*Funny (and scarry) .. * as a cherry on top of this cake at the end of this
scriplet updmap-sys is executed last *ONE MORE TIME!!!*
Few days earlier update of the texlive was without issues so I'm assuming
that someone pushed this craziness in last few days.
Probably it was not tested and/or slow upgrade was ignored.
Just started looking across source package .. few other issues after few
minutes of looking across it:
1) maintaining texlive in current form is totally unmanageable. Every
single change in any texlive even single file will cause cascade of
regenerating more than *5K BINARY PACKAGES!!!*
Which is totally CRAZY!!!
2)
$ rpm -qf /usr/lib/rpm/macros.d/macros.texlive
texlive-base-2016-10.20160520.fc26.noarch
So this package brings few useful rpm macros which can be used on other
texlive packages. That is of course VERY good!! HOWER:
- such macros are development resources and they are useful on building
OTHER rpm packages so WHY THE <censored> this file comes with texlive-base
package???????
- what was behind providing this set of system wide macros if LITERALLY ALL
TEXLIVE PACKAGES are build now from SINGLE SRC.RPM?????
It is kind of (Latin) massa tabulette/filler or 100% useless resource.
IMO: current Fedora texlive.spec it is really huuuge piece of s*t.
And/or it is PERFECT example of antyspec file.
Probably someone should call someone from Sevres to store current form of
this spec under glass cover to learn every other rpm developer how to NOT
write spec files because seems like separating some files in in
<subpackage> and <subpackage>-bin packages is solution of situation where
someone will be installing on for example x86 texlive packages in two
versions: x86_64 and i386.
I'm really interested who was this person trying to solve this MOL
("Meaning Of Life") dilemma instead asking themselves "do I really need to
have texlive installed for both archs and/or is set of useful cases when it
will be even need such thing is empty or not?"
In current texlive literally every font, or other tex file is separated
file along with source tex and pdf documentation is in separated packages?
PDFs are usually 10-20x bigger than text and almost 100% of TeX users will
be trying to find exact chapter in doc using google instead searching
across own texlive directory *because* as long as all this documentation is
not at all indexed searching over it even over remote 19200bps modem
(anyone has still something like this in use to prove that that I'm right?)
will take longer than trying to find some cheaper *on own system*!!!
3)
# strace -fe trace=file perl /usr/bin/updmap --sys --nomkmap --enable
Map=opensans.map 2>&1 | grep BUILD | head -2
[pid 25846]
open("/builddir/build/BUILD/texlive-2016/source/inst/lib/tls/x86_64/libkpathsea.so.6",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 25846]
stat("/builddir/build/BUILD/texlive-2016/source/inst/lib/tls/x86_64",
0x7ffc34847910) = -1 ENOENT (No such file or directory)
# strace -fe trace=file perl /usr/bin/updmap --sys --nomkmap --enable
Map=opensans.map 2>&1 | grep BUILD | wc -l
80
In other words kpathse has hardcoder RPATH directory from Fedora build
system:
# objdump -x /bin/kpsewhich | grep RPATH
RPATH /builddir/build/BUILD/texlive-2016/source/inst/lib
This of course slows down even more this whole crazy looping.
I think that it would be good to add to rpm-build macros executed on final
stages before assembly binary packages to stop build if any binary/text
file will have embedded strings which will contain paths with paths held in
build env %{_builddir} and %{_buildrootdir} macros.
Another thing should be at lease raising warning before generate package
that it contains any ELF binaries with RPATH.
Probably it would be good to back to more than ten years solution which
I've implemented in PLD by calling chrpath to report and remove all RPATHs
from binaries before generate rpm packages.
Will try to find time this weekend to implement and propose necessary
modification which may possibly expose/solve many similar issues in other
packages.
Packages so badly maintained on source tree level like texlive are probably
hundreds if not thousands .. texlive is not an exception so this issue
needs to be solved systematically.
TeX live is maintained IMO by real MORONS. If anyone have doubts about such
clam just try to think about maintaining still kpathse originally developed
to solve long time TeX directories trees search in DOS era (15-20sh yeas
ago) .. YES TeX still has embedded in his own source code guts something
which solves problems on systems which are not longer power even in
computers museums!
kloczek
PS. Just checked and upgrade still after more than 5h dnf not finished
upgrade.
In my case:
# ps aux | grep rpm
root 25803 0.5 0.0 120140 3264 pts/1 S+ 11:23 0:54 /bin/sh
/var/tmp/rpm-tmp.zx4oQi 0 0
# kill 25803
which caused on other terminal with running dnf to display:
warning: %triggerin(texlive-kpathsea-5:svn41139-10.fc26.1.noarch) scriptlet
failed, signal 15
Non-fatal <unknown> scriptlet failure in rpm package texlive-kpathsea
Non-fatal <unknown> scriptlet failure in rpm package texlive-kpathsea
Sorted for now texlive upgrade issue.
Above shows that problem sits in trigger scriplet.
BTW: few days ago I've mention here on commenting issues with dnf upgrade
executed from GUI thtr rpm is more or less dead because it allows to fiddle
with custom package post/pre/triggers scripts. According to more than
decade old Sun expertise which started development of IPS exactly these
issues been causing majority customers issues with patches and patches and
texlive today example is PERFECT example that this expertise is 100% right.
PS^2, Sorry to be so emotional but I have almost no respect to people with
elementary lack of sensitivity of simplicity.
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*