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.map|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.map|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.
"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.
--