Description of problem: There are a certain amount of scripts in the texlive distributions which are missed and are not exposed in /usr/bin/. These scripts are part of a standard texlive distribution and have already an installed man page. For instance typing "man mktexlsr" you see the script man page, but the corresponding executable/link is not included in /usr/bin. This is important, as it might be used by some other package in some %post, or during normal texlive maintainance. Such script is included in /usr/share/texmf-dist/scripts/texlive/mktexlsr, but it's not in PATH. Among mktexlsr I spotted other standard texlive missed scripts that are not exposed in /usr/bin, such as: dvired, dvi2fax, jadetex, mktexpk, kpsetool, kpsewhere, texconfig, texconfig-sys, texlinks, updmap-user, etc. Furthermore there is also a wrong exposed script, in /usr/bin/repstopdf which points to /../usr/share/texmf-dist/scripts/epstopdf/ which is a directory instead of an executable. It should instead be linked to /usr/bin/epstopdf instead. This is important too. I attach the diff for the spec file for the missed link currently spotted. Note that the cauldron version is affected too.
Created attachment 13225 [details] fix for the missed mktexlsr and other scripts in /usr/bin/ Current patch is for cauldron, but should work on mga8 too.
I raised the priority since the repstopdf wrong link breaks some important functionality in pdflatex. I also found other missed links. I attach a new patch for the spec file.
Priority: Normal => High
Created attachment 13226 [details] new fix for missed mkltexlsr, broken repstopdf link and other links
Attachment 13225 is obsolete: 0 => 1
Created attachment 13227 [details] new fix for missed mkltexlsr, broken repstopdf link and other links
Attachment 13226 is obsolete: 0 => 1
Assigning to Marc, the registered maintainer for texlive.
CC: (none) => davidwhodginsAssignee: bugsquad => mageia
@Giuseppe: can you please explain where do you have problems and what is not running correct. True we have some scripts which are not exposed in /usr/bin but this hadn't been a problem for years. So before I expose the whole world to /usr/bin it would be nice to know which application does not run or why it is needed. I just took over this package and did some changes for better maintenance and split it up, for installation issues and so on.
Created attachment 13229 [details] new fix for missed mkltexlsr, broken repstopdf link and other links fixed a typo in the previous patch.
Attachment 13227 is obsolete: 0 => 1
@Marc, first thanks for the maintenance job, reports were not a criticism. I included the patch just to agevolate the fixing. Some tool might be of not widespread usage so probably that's the reason why there weren't report before. The mktexlsr is part of a standard texlive. Yes there is texhash, but mktexlsr is supposed to be there too. In fact there is the manpage for it. What it does is to recreate/refresh the ls-R file database that it's used by kpathsea mechanism. Indeed it's supposed to be called directly from a PATH and not from internals /usr/texmf-dist/scripts/texlive..., as it might also run as unprivileged user. As package, for example "hevea" was calling it in %post scripts. Ditto for the other missed links. They are already included in basic texlive rpm packages, only problem it's that they are not exposed to /usr/bin as they should (also for coeherence with man pages which are instead included). AFAIK any distro based on texlive, including upstream texlive itself at ctan.org, it's exposing them all to /usr/bin or to a PATH. Also exposing them to /usr/bin/ wouldn't add any further package dependencies. A stuff that I found instead "missed" was the "xindy" executable. We included the manpage for it (just type "man xindy" to see) but not the executable. It's not included in the distro because it was not compiled. I've not yet reported about it because it seems that texlive SPEC file has a flag for building it after bootstrapping, so probably we just forgot to enable it. Probably that's deserve a testing with that flag enabled. There are still a few minor missed links not exposed that I've not included in the attached fix, such as "arara", and they are regarding scripts which are using java. I've not included in the attached fix patch because that would need java to be added as dependency in the basic texlive package, which we might not want, so that's worthwhile a further splitting (e.g. something like texlive-scripts-java) later. As for repstopdf report, here a simple testcase. Try to process with "pdflatex" this file: \documentclass{article} \usepackage[pdftex,dvips]{graphicx} \begin{document} \includegraphics{fig.eps} \end{document} Where fig.eps it's just any EPS file containing for instance: %!PS-Adobe-3.0 EPSF-3.0 %%BoundingBox: 0 0 100 100 50 50 49.5 0 360 arc closepath stroke With the correct links, pdflatex it's supposed to convert on the fly fig.eps to fig-eps-converted-to.pdf and include it. With the broken repstopdf link, instead it just gives the error: (/usr/share/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg))sh: line 1: repstopdf: command not found system returned with code 32512 As for other missed exposed links/scripts/tool, here is for instance a more detailed list. Each tool has already a man page (that we include) and was already part of texlive-collection-basic package. To know what the tool exactly does, just type "man <tool>": allcm allneeded bbl2bib bibdoiadd bibmradd biburl2doi bibzbladd chklref ctanbib ctanify ctan-o-mat dvi2fax dvired l3build mathspic musixflx musixtex fontinst pdfatfi pdflatexpicscale pedigree pmxchords ps2frag kpsetool kpsewhere mf2pt1 mktexpk pdfxup srcredact sty2dtx texconfig texconfig-sys texlinks texdoctk texexec texfot updmap-user texindy fmtutil-user Not exposing to /usr/bin/ wouldn't allow such tools to be called and would require a user to dig to internal paths at seek of them.
@Guiseppe: thanks. I sometimes use tex too. So I was wondering what problem exists here. I will have a look on it. The main problem with that package is, it so big and takes so much time to build and for the user to download the updates. One of the things I like to change is the ls-R etc updates to run in background / after all tex has been installed.
For the reported testcase with repstopdf, just copy what I pasted before in a file.tex, and a file.eps, and process with: pdflatex file.tex As for ls-R indexes generation IMHO with nowadays SSD disk speed it's tolerable. Running in background could also have as side effect to have multiple running system mktexlsr overlapping each other in case a sequence of texlive packages/subpackages are installed one after another. As for size. Yes, it's huge. But actually IMHO it's not bad packaged, and like this mostly works. Usually better a monolithic package that works than one zillion of scattered subpackages (e.g. one package per macro style) that don't work because don't have the right depedencies. Texlive is pretty monolithic by definition upstream. As for the updates, yes, even a single bit change would require redownloading the updates (but a user might also looks what the update does and also decide to not update a package in his installation). But that's so for any big package. Some other distro used rpmdelta in the updating system for mitigating the download size in such cases, but IMHO it's more harmful than other, and dunno if it's still used somewhere. BTW, there is out texlive 20220321. Upgrading seems compiles pretty well with just current cauldron SPEC files and the included above fixes (apart the time of downloading of 3GB of new data during building). Instead would be fine to have packaged another documenting tool (maybe at least the upstream binaries repackaged in non-free): pandoc, but that's another story.
it is not just ls-R index, it is a whole bunch of creations (e.g. fonts) which are generated again and again during each install. it helds up the whole update process. Its quite the same as we had before man-pages updates are triggered by systemd.
You mean the updmap stuff?
yes.
Hi, I noticed you upgraded in cauldron texlive to 20220321. However I see that the repstopdf problems were still there. Looking the the spec file there is link: ln -sf %{texmfdistdir}/scripts/epstopdf repstopdf while it should be: ln -sf %{_bindir}/epstopdf repstopdf i.e. with repstopdf pointing to /usr/bin/epstopdf and not to ln -sf %{texmfdistdir}/scripts/epstopdf repstopdf as /usr/share/texmf-dist/scripts/epstopdf/ is a directory and not a file. In fact if you type: $ repstopdf you get: bash: repstopdf: command not found As for the extra links, thanks for adding. However would be possible there to reorganize the block of links in alphabetical order sorted by the link names? I.e. sorted (more or less) on the last column? In this way would be more easy to debug and to spot new entries, new removing, etc. Thanks.
thx for your feedback - just a first build; I'll recheck some of the files. I don't have much time atm - but I will check if I can change a few things and make it e.g. more readable (sorted - but I prefer not doing it by hand)
Well, for a first build is good looking. For sorting out, you can use something like: cat block_links.txt | awk '{print $NF,$0}'| sort -k1,1 | cut -f2 > block_links_sorted.txt where block_links.txt is a file where you have pasted the block of spec file which is settings the bindir links. As results block_links_sorted.txt would contains the list sorted by the destination links. It should be only tuned further by hand for the blocks enclosed in some %if. Note that 'texexec' is part of context, so it should be moved to such package (you might look at the attached patch), with the %exclude from main.
Created attachment 13260 [details] new set of patches for fixing texlive-texmf and texlive packages
Attachment 13229 is obsolete: 0 => 1
Hi. I added the archive texlive-fixes-20220520.tar.gz. It cointains all the patches to fix the remaining problems that I reviewed in texlive (in particular the repstopdf problem was still there, and we introduced also a new one in the previous stage). The archive contains 3 directories: texlive/ texlive-texmf/ texlive-fixes/ here is what they do: 1) The dir "texlive" contains SPECS and SOURCES with the replacement for the package 'texlive' as it's should be downloaded from svn. There are fixes to build the texlive with xindy. Basically the previous texlive remained in bootstrap mode and we missed to build xindy. The package was ready to build xindy but in the later texlive(s) it need enabling a further configure switch and adding a further dependency (probably they weren't needed in the original spec file, but over the years texlive changed). The patch in SOURCES needs to be moved in the corresponding dir of the svn tree (it fixes a problem with help of xindy). 2) Dir "texlive-texmf". SPECS and SOURCES contains the newer fixed/revised specfile for texlive-texmf.spec. SOURCES cointain also a new patch which need to be added in svn SOURCES, and also a fixed filelist that fixes duplicate entries for some fonts. I also cleaned up a bit the SPEC filefor more readability and did an alphabetical sorting of the links section, so they can be easily spotted. I also added a conditional building flag called 'draft' that when set to 1, it will speed-up the package building (by skipping some check): useful when building the package for a new version for the first time to check that the filelist and building are correct. 3) Dir "patching". This directory contains the texlive-texmf/SPECS with all the 38 patches used to arrive at the final configuration of texlive-texmf.spec; the patches are in mbox mode, with a little explaination of what they do. By applying all the patches in sequence one-by-one, using the provided script 'build-patched-spec.sh', you get exactly the same final texlive-texmf.spec that you have at stage 2) dir. Ditto for the texlive/SPECS dir (but there you have only one patch). In this way you can examine the patches. Actually the patches are for current cauldron texlive/texlive-texmf, I checked building with these patches and everything seems ok. Once upgraded in cauldron with a new build we could merge the fixes to mga8.
Created attachment 13266 [details] new set of patches for fixing texlive-texmf and texlive packages This version adds also the patch 0039 to fix permission of mptopdf, etc.
Attachment 13260 is obsolete: 0 => 1
Created attachment 13267 [details] new set of patches for fixing texlive-texmf and texlive packages This version adds the patch 0040 for adding the missed pstoedit dependency for purifyeps and the missed buildrequires for texlive-dist for xindy.
Attachment 13266 is obsolete: 0 => 1
Created attachment 13268 [details] new set of patches for fixing texlive-texmf and texlive packages This version adds patch 0041 to fix executable permission on some file.
Attachment 13267 is obsolete: 0 => 1
Created attachment 13288 [details] set of patches for fixing texlive-texmf and texlive packages for mga8 Here is the corresponding complete set of fixes for texlive for the older version for mga8.
I can't follow up your suggestions. I'm still not sure, if I'm willing to expose all executables and scripts from texlive to /usr/bin.
Well, that's simply the way used in any texlive, and in texlive of any distro. Removing the links (or even having wrong links like for repstopdf) would make the package partially broken. On the other hands the links were originally partially present in the original texlive package. They are not removed for some special reason, but they are removed in the main SPEC file just for splitting in texlive and texlive-texmf (removed in texlive and rebuilt in texlive-texmf). Only problem is that over the time the original links/commands changed, from release to-release but SPEC file were not re-generating of correct the links in texlive-texmf, following the evolving of texlive over time.
e.g. I'm not willing to do patches like this: ./texlive-texmf/SOURCES/0001-Fix-italian-spelling-in-yplan.sty.patch If there is a mistake in that package, IT MUST be submitted to the owner of that tex package first, and a bug has to be created in texlive.
Ok, I found that while veryfying that command, and that's pretty trivial, it's just fixing a typo in month names and that fix won't undermine package functionalities. :-)
Furthermore that's was the reason why i splitten all the 41 patches one-by-one for cauldron, to give the opportunity to better check, rather than in one single stage. I included only the final result for mga8, since they were substantially (apart one) the same patches as for cauldron.
no that's not the point. We should not fix mistakes or errors while they still exist upstream. So everyone else will stumble upon them. If you found errors or mistakes, put them in the bugtracker upstream. We will just add patches to make software compatible to our environment.
updated texlive package on cauldron to a generic version for file links. If you have further suggestions, please tell. But I will not look into 48 patchsets.
Dear Marc, thanks for the new update. Note that the 48 patchset were just a courtesy that I used to give you the explanation of every single change, however the the attached tarballs includes also the final SPEC files, which have all the patches merged in one shot. Note that there were patches for both texlive (because the spec file was left in bootstrap mode and forgot to eanble the xindy binary) and texlive-texmf. All the patchsets were tested for building and for usage against the problems listed. As for your new version I hadn't yet the opportunity to test the binaries. I just looked at the diff of the SPEC files: the way you used to build all the links in one shot is certainly smart, however I don't know if it would add more links than needed or also left out links not depending on the .pl|.sh|.lha, etc., but on format files (for instance I might cite luacsplain which is a soft link to %_bindir/luatex), or also have overlapping on other binaries provided elsewhere. I would have to rpmdiff both the new and my binaries. In any case since I read on cauldron ML that there were problems on installing current TL, in case of impasse, you might just revert to my included SPEC file as is, and then later enable your more generic|simplified way to build the links you implemented, with all the required exceptions.
Patchset: The way you committed the patchsets was not obvious to me. I prefer simple patches this way: + #Add dependancy for xxx + Requires: yyy Or just a patched spec file with comments, so I can diff and see what you suggest. A new version is running on the build system. If any links still missing, give me a note. Where does this "list of commands" like "luacsplain" come from? To be honest, I'm not very active in using (la)tex, I used it more some time ago.
Hi, I've not committed the patches to svn. Just the attach here. The way I used was to provide the patch (they were also in numbered ascending order starting from 0001) for SPEC in "git mbox" (git am) format; it was unusual, but has an advantage of giving multiline explaination of what exactly is done. Basically it's just a patch with a comment on top. Almost every patch included patches basically just texlive-texmf.spec, so in the end it's like you were already getting exactly the "diff" plus extended comments, step-by-step. Using the short form in one line only, as of typical svn would have been probably too much simplified. I think that the single extra patch for trivial typo fixing in the name of the months in the end just confused the ideas (so just forget it for now). Some of the missed links (and missed executables such as xindex), beyond a direct hit because required in some tool, comes from the presence of the already generated .fmt files which needs to be accessible, and also from revisioning against a working complete TL (upstream) binary installation. I also further cross/compared them to the presence/absence in other distro TL (e.g. deb, FC, etc.). As for tex/latex, yes, you are right, currently TL with respect to some year ago added a new levels of complexity due to the adding of new (compatible) TeX engines, and macro packages, that adds many extensions. So beside standard TeX/pdfTeX with latex2e, there are new engines with extensions (e.g. for using opentype font families), which embeds lua, embeds metapost for figures, includes new macro towards latex3, and many little scripts. And also some of them will be subject to further change in TL2023. E.g. ConText in TL2023 will be based on a newer engine called 'luametatex' engine (not yet included in TL2022 but already available standalone upstream).
Why is it you're following the development of tl so tight? Will you take over the maintenance? As I told, I use latex very rare, but I still use it. And I was disappointed that mga does not have any maintainer and it was shipped just as one big unit. So I started to clean up the package and tried to sort things up. One of my ideas was to get an equal structure like the stand-alone-installer and tried to use the installer in the build process. But I canceled this idea, it was too complicated and the package is just big and even unpacking the source takes ages.
TL is big because...is big. Before TL there was teTeX, which was smaller, but then around 15 years ago IIRC the developer stopped the maintanership. In theory one it's not obeyed to use TL and might build its own minimalist TeX system without TL, starting from upstream web2c and then adding components to single packages. Only problem is that in this way you'll have to maintain the components (macro/fonts) one by one (and also verifying mutual compatibility), otherwise they'll become obsolete very soon. But in the end this is a sort of doing at a smaller scale what TL developers do. Unpackacking the sources takes ages because it's a huge archive in tar.xz, and xz uncompressing doesn't use multithreading. There is pxz or similar utils that uncompress also xz files in multithreaded mode, but we don't have them packaged in our distro, and even if we would, they wouldn't be directly supported in rpm %setup stage. A solution is to repack once the TL source tarball in .lzma at a cost of a slightly bigger compressed archives. lzma uncompressing is way faster and also work multithreaded. As for further speed up rpm packaging, if you look at the provided texlive-texmf.spec, there is is the conditional flag "%draft". Setting it to 1 on top of the spec file and you'll skip a few checks in rpm that takes ages during building. Useful for verifying that building works smoothly.
yeah I'm aware of the history of teTex, TL, ... Recompressing does not help much - I just wanted to state, that it is quite hard to deal with that package. And testing is slow. Due to the size, I do the builds only on build system, so draft does not help much. Found a few more windows executeables, just removed. If you have further things missing, or improvements, just tell. I'd like to split up that big package some more (not to have a 600MB rpm), but maybe it is not worth doing it.
Yes TL is a "big beast" to tame :-) Regarding unpacking the lzma vs xz: /usr/bin/time xz -cd texlive-20220321-texmf.tar.xz > /dev/null takes 2 minutes and 57 seconds on a 4 core CPU. While: /usr/bin/time zstd -cd texlive-20220321-texmf.tar.zst > /dev/null takes 3.97 seconds. In the end you'll save around 3 minutes. For splitting further, it's not worth it. For the executables, from a first sight, I just did a rpmdiff between yours and the one derived from the patches I posted, and there are still problems. For instance, these ones are missed: /usr/bin/convbkmk /usr/bin/dvilualatex-dev /usr/bin/kpsepath /usr/bin/kpsexpand /usr/bin/latex-dev /usr/bin/listings-ext.sh /usr/bin/lollipop /usr/bin/luacsplain /usr/bin/lualatex-dev /usr/bin/optex /usr/bin/otfinfo /usr/bin/pdflatex-dev /usr/bin/platex-dev /usr/bin/rpdfcrop /usr/bin/uplatex-dev /usr/bin/xelatex-dev then there are a lot of links which doesn't point to executables, or also links linked to text files, such as: /usr/bin/CHANGES.rst /usr/bin/Command.pm /usr/bin/Environment.pm /usr/bin/IfElseFi.pm /usr/bin/KeyEqualsValuesBraces.pm /usr/bin/LICENCE /usr/bin/NamedGroupingBracesBrackets.pm /usr/bin/README-scripts plus there are more other which shouldn't be exposed or that are not even executable because they don't have sh-bang, and also some other one, such as "ebong", which is broken (e.g. it needs to be fixed, because doesn't work with python3, that's why I haven't added yet it in my patch list), and some which is already provided in texlive package and thus overlaps (/usr/bin/ps2eps IIRC). Also still missed xindex in texlive package, because not built (the SPEC file should go out from bootstrap mode). texlive-collection-basic still misses "pstoedit" to Requires:, because it's needed to purifyeps (see patch 0040). texexec and luatools should be moved to the context subpackage (see patch 0008, 0009).
- extract is done on the build server - I dont't care. - files: I will not expose -dev files; for the other's I'm gonna look - bad files: true I'm checking why the have the executeable bit and will remove them (need some cleaning) - ebong - does not matter if it works or not. - ps2eps is already fixed. - pstoedit: no, maybe suggests - if we try to fullfill the requirements of everything, we have to download the world - texexec, luatools: no; moved all executeables to basic package; since links will be generated in the basic package.
For the -dev files the corresponding man pages are already provided/exposed in /usr/share/man/.
ok, I remove the man pages
where should these files link? /usr/bin/lollipop /usr/bin/luacsplain /usr/bin/optex /usr/bin/otfinfo What do you mean? Also still missed xindex in texlive package, because not built (the SPEC file should go out from bootstrap mode). xindex is not provided by the package.
ln -sf %{_bindir}/tex lollipop ln -sf %{_bindir}/luatex luacsplain ln -sf %{_bindir}/luatex optex ln -sf %{_bindir}/otfinfo-texlive otfinfo otfinfo (see patch 0017), is because we renamed otfinfo to otfinfo-texlive because it was conflicting with a binary of the same name of the package openmpi, but now since openmpi 2.0.1, otfinfo is no longer provided in openmpi, so it should be provided the standard name. xindex is important because it's the indexing tool supporing unicode. It's provided in the package texlive.spec and it's not actually built because the texlive.spec file remained in "bootstrap mode". While the procedure, already prepared in the current texlive.spec spec file is to bootstrap texlive without xindy enabled, then build both texlive and texlive-texmf, then rebuild a newer texlive rpm with xindy enabled and with the newer built texlive-texmf. Basically it should be compiled with %define enable_xindy 1 on top of the spec file, and also adding --enable-xindy near --enable-xindy-rules. Also these new BuildRequires should be added: BuildRequires: texlive >= 20220321 BuildRequires: texlive-fonts-sources >= 20220321 to texlive.spec due to change in the docs.
And for rpdfcrop, kpsepath, kpsetool ln -sf %{texmfdistdir}/scripts/pdfcrop rpdfcrop ln -sf %{texmfdistdir}/scripts/texlive-extra/kpsetool.sh kpsepath ln -sf %{texmfdistdir}/scripts/texlive-extra/kpsetool.sh kpsetool for convbkmk (used by uplatex), the autolink scripts provided the link to convbkmk.rb, while the link name is without .rb, so: ln -sf %{texmfdistdir}/scripts/convbkmk/convbkmk.rb convbkmk
Sorry, rpdfcrop is intended to be a link to: ln -sf %{_bindir}/pdfcrop rpdfcrop
Just to avoid confusion: xindex and xindy are TWO distinct tools. xindy must be generated in texlive and is a binary executable. xindex is a link to xindex.lua.
no you are totally confusing. Why don't you take over the texlive package?
I don't plan to take over the texlive packages. You are already doing a good job. BTW, note that here: https://svnweb.mageia.org/packages/cauldron/texlive-texmf/current/SPECS/texlive-texmf.spec?r1=1865280&r2=1865342 you linked pdfcrop TO rpdfcrop, while should be the opposite, i.e. linking rpdfcrop TO pdfcrop. As for xindy [the binary] (the way how to fix it where already shown in the attached archive in the texlive.spec), but basically is what I've just described above.
xindy is enabled, but I don't know what u want with xindex. I'll come back to this later - I've got some real work to do.
Forget xindex.
I cited xindex because here you had added a line: https://svnweb.mageia.org/packages/cauldron/texlive-texmf/current/SPECS/texlive-texmf.spec?r1=1865342&r2=1865343 line 423, where you were removing "xindex", while indeed xindex in texlive-texmf.spec should be left as is.
There is still some files missed. In texlive-texmf.spec you added #remove scripts we have in psutils, gs or texlive rm -f texmf-dist/scripts/tex4ht/xhlatex.sh rm -rf texmf-dist/scripts/psutils \ texmf-dist/scripts/chktex \ texmf-dist/scripts/ps2eps but only psutils is needed to be removed. chktex is needed, and in fact removing it breaks some commands, e.g. deweb (for which there is a man page, man deweb). xhlatex too it remains a broken link. xhlatex is not provided in texlive package, or to be precise it's provided only as soft link which points to /usr/share/texmf-dist/scripts/tex4ht/xhlatex.sh which should have been in texlive-texmf pckage, but that was removed by the rm above. ps2eps has a man page (see man ps2eps) but indeed is not provided by ghostscript, so there is no conflict and shouldn't be removed. The command in /usr/bin/ps2eps should be a soft link to /usr/share/texmf-dist/scripts/ps2eps/ps2eps.pl. Indeed the command provided in ghostscript is "ps2epsi", which has a similar name, but it's different and it's another one, from which probably the confusion. xindy there is still some problem of missing, but let's see later.
Also these links shouldn't be in /usr/bin/: README-scripts CHANGES.rst Command.pm Environment.pm IfElsefi.pm KeyEqualsValuesBraces.pm LICENCE NamedGroupingBracesBracket.pm setkeycindy.txt tlcockpit-jdk8.jar ketcindylib*.txt albatross.jar defaultSettings.yaml ketpiccurrent_rep2e.r ketpiccurrent.r spelling-main spelling-recurse spelling-stage-1 spelling-stage-2 spelling-stage-3 spelling-stage-4 as they are not executable commands or links to executable commands.
There were more of that list that I included in this fix: https://svnweb.mageia.org/packages/cauldron/texlive-texmf/current/SPECS/texlive-texmf.spec?r1=1865361&r2=1904095 The problem with xindy was also fixed too (the problem was to remove just the link in bindir, but not the scripts in texmfdistdir. At this point as of texlive-texmf-20220321-10.mga9 this bug can be considered RESOLVED. Remains for mga8 which a fix was posted in an attach above.
we will not fix mga8 anymore. Your cleanup code is way to complicated. Why didn't you first add some more extensions to exclude before putting in a bunch of files?
and btw. why did you change the spec? Just because I was busy at the weekend???
Using some extension would risk to remove/kill some real command again. It could be refined then.
that's ok for me. Better to have such a list, than a full list of files.
Yes, your way was pretty fine. We could reach the list from top or from bottom :-)
building. Will try to change the upstream source. That is totally nonsense.
Resolution: (none) => FIXEDStatus: NEW => RESOLVED