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>*
10:02 a.m.
On Fri, 14 Oct 2016 15:35:00 +0100
Tomasz Kłoczko <kloczko.tomasz(a)gmail.com> wrote:
Hi,
...snip...
Can you please refresh your memory on the Fedora Code of conduct?
https://getfedora.org/code-of-conduct
Making personal attacks or calling people names is not acceptable.
There have been some rough issues with texlive over the last few weeks,
but thats only because spot is trying to improve it and get it updated.
Bugs happen (especially with such a gigantic package).
The bug you hit (and many others) is:
https://bugzilla.redhat.com/show_bug.cgi?id=1384777
you can respectfully follow along there.
kevin
11:33 a.m.
On 14 October 2016 at 16:02, Kevin Fenzi <kevin(a)scrye.com> wrote:
Making personal attacks or calling people names is not acceptable.
Did I call someone name? .. hmm ??
My comment is not about persons but about exact work which has been done by
someone.
It refers not to who done thys but HOW it has been done.
What I've wrote is as well not accusation or empty claim but has enough
TECHNICAL justification.
Looking on history of the changes in texlive.spec looks like people
responsible for sending to build systems and signing packages been
tolerating this madness more than half year.
Q: not who accepted this but WHY? Why someone not refused to move more 5k
packages after single build request?
Bad thing happens .. and sometimes disasters happens even because someone
not intentionally done something (which I believe had happen this time).
However someone as well approved results of those texlive changes so
fragmenting texlive to include main Fedora tree. So what I've wrote is not
about exact people but more about failing processes which not blocked to
release so badly done packages.
Packing thousands archive files in single source package should be kind of
first alarm .. but it wasn't!!!
Again: not who done this but WHY? Maybe it was perfect good reason to do
this exactly this way (?) but really I don't see it.
If it is true .. maybe can someone help me to understand intention
packaging texlive like it is now?
If someone personally feels touch by what I've wrote about texlive or
packaging texlive .. really it is not my problem.
I'm only trying to shake this tree .. instead smacking me using political
correctness better would be just start asking (using some kind of analogy)
"how it was possible to climb so high on this unattended tree?"
If it is not obvious that only this kind of "WHY?" questions are bouncing
in my head .. really I've nothing to add than (Latin) "errare humanum est
perseverare autem diabolicum".
Learning process is not possible without making mistakes and this is why it
is not possible to learn about something only by reading about it. I'm as
well fully aware that many people here trying to help on Fedora development
in reality are learning .. and it is nothing bad with this.
I know this because I've started almost 20 years ago trying to build my
first package. I made in the past enough number of times mistakes (not only
on packaging) to learn really a lot things .. and still it is even more
ahead of me.
What we are personally doing when someone spots our mistake says something
about us .. and only us.
So .. don't worry. I'm going patiently sit down and wait until people
maintaining texlive at least few times will try to fix not only this
trigger issue but whole texlive packaging approach :)
Have a good weekend :)
kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
11:52 a.m.
On Fri, 2016-10-14 at 17:33 +0100, Tomasz Kłoczko wrote:
On 14 October 2016 at 16:02, Kevin Fenzi <kevin(a)scrye.com>
wrote:
> Making personal attacks or calling people names is not acceptable.
>
Did I call someone name? .. hmm ??
"TeX live is maintained IMO by real MORONS."
is what you wrote.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
6:03 p.m.
"TeX live is maintained IMO by real MORONS."
is what you wrote.
Yes it is.
Probably you never had occasion to have closer look what exactly is
maintained in texlive source tree.
I had fist time been trying to contemplate what exactly is texlive tree
about 9 years ago.
What was scarry 9 years ago now is even more scary today.
Will try to present you what is in texlive today over now available
rpm packages.
So lets go alphabetically:
Name : texlive-ESIEEcv
Summary : Curriculum vitae for French use
Description :
The package allows the user to set up a curriculum vitae as a
French employer will expect.
Package contains style template to write some CV. Using google you can find
few examples of how it looks like.
Number of google results: ~2.9k. I can give anyone £10 to anyone who in
last 5 years been using this template installed on any Linux distro
installed from packages to wrote own CV.
Name : texlive-allrunes
Summary : Fonts and LaTeX package for almost all runes
Description :
This large collection of fonts (in Adobe Type 1 format), with
the LaTeX package gives access to almost all runes ever used in
Europe. The bundle covers not only the main forms but also a
lot of varieties.
Few questions:
What is the size of the cross section of the sets: "we are using Linux" and
"we uses runes fonts"?
Maybe few artist in whole word are using runes .. how many of them are
using Linux?
Why those vectorised resources are only available as TeX users?
Why TeX is not prepared to use system wide Type1 font and is not able to
share those fonts with other applications?
Why most Type1/TTF fonts are at least served three times as: ghoscript
fonts, X11/Weyland fonts and TeX fonts?
Why TeX live is not able to share those fonts with other applications?
Maybe someone who what to quickly prepare some post card want to use those
runes as some funny markings? However probability that he/she will use TeX
is probably the same as probability that bucket of water left on open fire
will freeze (according to quantum physics probability of something like
this is greater than zero) and probably more likely will try to use
LibreOffice. Isn't it?
Does Fedora really need to regenerate package with these fonts every time
when someone will change even single bit in any TeX live resources?
Name : texlive-a2ping
Summary : Advanced PS, PDF, EPS converter
Description :
a2ping is a Perl script command line utility written for Unix
that converts many raster image and vector graphics formats to
EPS or PDF and other page description formats. Accepted input
file formats are: PS (PostScript), EPS, PDF, PNG, JPEG, TIFF,
PNM, BMP, GIF, LBM, XPM, PCX, TGA. Accepted output formats are:
EPS, PCL5, PDF, PDF1, PBM, PGM, PPM, PS, markedEPS, markedPS,
PNG, XWD, BMP, TIFF, JPEG, GIF, XPM. a2ping delegates the low-
level work to Ghostscript (GS), pdftops and sam2p. a2ping fixes
many glitches during the EPS to EPS conversion, so its output
is often more compatible and better embeddable than its input.
If anyone today will need to convert any of those formats to EPS or PDF
more likely will use convert from ImageMagic.
Isn't it?
I'll stop here after only three examples but still more than 2.5k more
remains.
Really please try to go package by package. In source texlive tree all this
garbage has own .tlpobj file marking this as separated TeX package where in
reality most of those resources are needed by anyone. In most cases they
are kind of examples, POCs or something which was useful but 10 years ago.
I don't remember name of this TeX package but I'm almost 100% sure that it
is still in texlive tree somewhere. "The Package" generates using metapost
cube view with visable only one side, two sides and EVEN THREE sides!!! 8-O
As example of generating some graphics it was obsolete in the time when
people started using Corel Draw in Win 3.11 era (anyone remember this
program?).
Probably more than 50% (if not more than 80%) of the TeX live is like this.
Most of the resources should be archived and preserved for next generation
cyber archeologist however now they should not be served as regular rpm
packages because it will make look Fedora stupid ("who is more stupid?
someone who is stupid or someone else who follows stupid one?").
I'm pretty sure that someone who had this grand idea converting TeX
packages to rpm packages never red even 5% of the descriptions of those
"packages" stored in .tlpobj files or been trying to as themselves "do I
really need to package this TeX package as rpm one?"
And now back to what I wrote about TeX maintainers.
TeX live is more like black hole sucking every bit of anything related to
TeX. Ones something stored in the tree doesn't matter is it still usefull
or not still will be "maintained". Those people are thinking that they are
doing great job but in reality as now TeX live holds probably almost
everything what was produced as TeX tool/example it shows how small this
world is.
What happens from loooong time with TeX recalls me something which is
called "Parkinson law" (no, it has nothing to do with Parkinson disease)
which says "work expands so as to fill the time available for its
completion". One of the Open Source "laws" says that "ones some source
code
reaches some critical mass number of people want to maintain it will be
always greater than zero". As consequence it could be transformed to
"amount of time spend on some OSS projects used to go to infinity even
without any functional/technical progress".
I'm pretty sure that TeX maintainers will be working on TeX to the end of
the World .. and probably one day longer.
If someone still is not convinced that using word which I've used is not
accurate/proper I'm really opened on .. more precise propositions. And I
promise stop using this word in context of TeX maintainers.
And at the end last two sentences as kind of final conclusion:
IMO current Fedora problem with TeX live is that some people (I'm
pretty sure good people) are trying to follow (probably unconsciously)
trying replicate in rpm packages with almost 100% accuracy what was
produced by TeX maintainers ..
TeX is great tool and I'm still able to amaze quality of the typography on
printed single A4 page people who never saw document printed from compiled
TeX document (especially if it is formal document which will be read by
someone who cares about aesthetics), however what needs to be delivered as
dist rpm packages really needs to be very carefully chosen.
kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
6:12 p.m.
On Sat, 2016-10-15 at 00:03 +0100, Tomasz Kłoczko wrote:
> "TeX live is maintained IMO by real MORONS."
> is what you wrote.
Yes it is.
Probably you never had occasion to have closer look what exactly is
maintained in texlive source tree.
[snip]
1. Yes I did, in fact.
2. That's not the point. The point is that you violated the code of
conduct. Kevin pointed this out:
"Making personal attacks or calling people names is not acceptable."
and you denied it:
"Did I call someone name? .. hmm ??"
So I pointed out that, yes, you *did* call someone a name.
Calling other Fedora contributors (or, indeed, anyone at all) 'morons'
is not acceptable. It doesn't matter if you're *right* that there are
issues in the texlive package. It is not acceptable to call the people
who maintain it 'morons'.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
6:55 a.m.
On 15 October 2016 at 00:03, Tomasz Kłoczko <kloczko.tomasz(a)gmail.com> wrote:
> "TeX live is maintained IMO by real MORONS."
> is what you wrote.
Yes it is.
Probably you never had occasion to have closer look what exactly is
maintained in texlive source tree.
I had fist time been trying to contemplate what exactly is texlive tree
about 9 years ago.
What was scarry 9 years ago now is even more scary today.
Will try to present you what is in texlive today over now available rpm
packages.
What exactly are you using TeX for? The following examples suggest you
aren't very clear on its uses:
So lets go alphabetically:
Name : texlive-ESIEEcv
Summary : Curriculum vitae for French use
Description :
The package allows the user to set up a curriculum vitae as a
French employer will expect.
Package contains style template to write some CV. Using google you can find
few examples of how it looks like.
Number of google results: ~2.9k. I can give anyone £10 to anyone who in last
5 years been using this template installed on any Linux distro installed
from packages to wrote own CV.
Style templates are how LaTeX is supposed to work, for a re-used
document format you fill in various parameters in your .tex document
and it generates the format for you, creating or adjusting your own
style is more involved. Note this comes from CTAN, you don't need to
install this package yourself, but if you require it it is much easier
to install from a fedora package.
Name : texlive-allrunes
Summary : Fonts and LaTeX package for almost all runes
Description :
This large collection of fonts (in Adobe Type 1 format), with
the LaTeX package gives access to almost all runes ever used in
Europe. The bundle covers not only the main forms but also a
lot of varieties.
Few questions:
What is the size of the cross section of the sets: "we are using Linux" and
"we uses runes fonts"?
Maybe few artist in whole word are using runes .. how many of them are using
Linux?
"Artist"... TeX is largely used by academics, and the whether people
wish to use runes (for example for books and papers) and are using TeX
to do so are probably not independent factors.
Why those vectorised resources are only available as TeX users?
Why TeX is not prepared to use system wide Type1 font and is not able to
share those fonts with other applications?
Why most Type1/TTF fonts are at least served three times as: ghoscript
fonts, X11/Weyland fonts and TeX fonts?
Why TeX live is not able to share those fonts with other applications? Maybe
someone who what to quickly prepare some post card want to use those runes
as some funny markings? However probability that he/she will use TeX is
probably the same as probability that bucket of water left on open fire will
freeze (according to quantum physics probability of something like this is
greater than zero) and probably more likely will try to use LibreOffice.
Isn't it?
TeX predates Type1 fonts, though most distributions support them, and
is used for its typesetting abilities. The needs of someone who wants
to do a little cultural appropriation for a quick postcard are going
to be less stringent than someone who actually wants to use the
language, but they'll be in luck, because there is a runic block in
unicode and fonts that support it outside TeX
https://en.wikipedia.org/wiki/Runic_(Unicode_block).
Does Fedora really need to regenerate package with these fonts every
time
when someone will change even single bit in any TeX live resources?
Name : texlive-a2ping
Summary : Advanced PS, PDF, EPS converter
Description :
a2ping is a Perl script command line utility written for Unix
that converts many raster image and vector graphics formats to
EPS or PDF and other page description formats. Accepted input
file formats are: PS (PostScript), EPS, PDF, PNG, JPEG, TIFF,
PNM, BMP, GIF, LBM, XPM, PCX, TGA. Accepted output formats are:
EPS, PCL5, PDF, PDF1, PBM, PGM, PPM, PS, markedEPS, markedPS,
PNG, XWD, BMP, TIFF, JPEG, GIF, XPM. a2ping delegates the low-
level work to Ghostscript (GS), pdftops and sam2p. a2ping fixes
many glitches during the EPS to EPS conversion, so its output
is often more compatible and better embeddable than its input.
If anyone today will need to convert any of those formats to EPS or PDF more
likely will use convert from ImageMagic.
Isn't it?
From its description this looks like an interface layer, since TeX's
main use is producing pdf and eps it's not particularly surprising it
has one. ImageMagick itself uses ghostscript.
I don't remember name of this TeX package but I'm almost
100%
sure that it is still in texlive tree somewhere. "The Package"
generates using metapost cube view with visable only one side,
two sides and EVEN THREE sides!!! 8-O
As example of generating some graphics it was obsolete in the
time when people started using Corel Draw in Win 3.11 era
(anyone remember this program?).
I don't, but this hypothetical program would be a good example of
literate programming. You can certainly draw a diagram in Inkscape,
but if you have a large document with lots of these you now have a
directory full of images and their source files, and changing them
means editing these, getting the right one, replacing the included
image. Doing this under source control becomes a real pain. More
concrete example (one I know exists), packages to draw Feynman
diagrams. If you're preparing a professional publication you don't
want to be drawing these by hand.
Probably more than 50% (if not more than 80%) of the TeX live is like
this.
Most of the resources should be archived and preserved for next generation
cyber archeologist however now they should not be served as regular rpm
packages because it will make look Fedora stupid ("who is more stupid?
someone who is stupid or someone else who follows stupid one?").
I'm pretty sure that someone who had this grand idea converting TeX packages
to rpm packages never red even 5% of the descriptions of those "packages"
stored in .tlpobj files or been trying to as themselves "do I really need to
package this TeX package as rpm one?"
And now back to what I wrote about TeX maintainers.
TeX live is more like black hole sucking every bit of anything related to
TeX. Ones something stored in the tree doesn't matter is it still usefull or
not still will be "maintained". Those people are thinking that they are
doing great job but in reality as now TeX live holds probably almost
everything what was produced as TeX tool/example it shows how small this
world is.
TeX has been around since 1978, so that it hasn't sucked everything in
yet suggests it's not really a black hole. Having put LaTeX to serious
use in the past I've been pretty glad when I've found that a package
or style is available as rpm, because maintaining a TeX install
manually is not pretty.
--
imalone
http://ibmalone.blogspot.co.uk
2:58 p.m.
On 15 October 2016 at 12:55, Ian Malone <ibmalone(a)gmail.com> wrote:
> What was scarry 9 years ago now is even more scary today.
> Will try to present you what is in texlive today over now available rpm
> packages.
What exactly are you using TeX for? The following examples suggest you
aren't very clear on its uses:
You are losing the point.
It doesn't matter how and for what I'm using TeX. I've not said even single
word about how I'm using TeX.
I'm questioning generally about packaging every piece of garbage already
been sucked into texlive and repeating patterns of texlive packages 1:1
into rpm ones.
Style templates are how LaTeX is supposed to work, for a re-used
document format you fill in various parameters in your .tex document
and it generates the format for you, creating or adjusting your own
style is more involved. Note this comes from CTAN, you don't need to
install this package yourself, but if you require it it is much easier
to install from a fedora package.
Seems you are thinking that I don't know for what are styles for, and I
need some explanation. completely ignoring exactly why this style is
delivered as rpm package.
Name : texlive-allrunes
[..]
Few questions:
> What is the size of the cross section of the sets: "we are using Linux"
and
> "we uses runes fonts"?
> Maybe few artist in whole word are using runes .. how many of them are
using
> Linux?
"Artist"... TeX is largely used by academics, and the whether people
wish to use runes (for example for books and papers) and are using TeX
to do so are probably not independent factors.
So again: what is the size of cross section of those two sets?
Why those vectorised resources are only available as TeX users?
> Why TeX is not prepared to use system wide Type1 font and is not able to
> share those fonts with other applications?
> Why most Type1/TTF fonts are at least served three times as: ghoscript
> fonts, X11/Weyland fonts and TeX fonts?
> Why TeX live is not able to share those fonts with other applications?
Maybe
> someone who what to quickly prepare some post card want to use those
runes
> as some funny markings? However probability that he/she will use TeX is
> probably the same as probability that bucket of water left on open fire
will
> freeze (according to quantum physics probability of something like this
is
> greater than zero) and probably more likely will try to use LibreOffice.
> Isn't it?
TeX predates Type1 fonts, though most distributions support them, and
is used for its typesetting abilities. The needs of someone who wants
to do a little cultural appropriation for a quick postcard are going
to be less stringent than someone who actually wants to use the
language, but they'll be in luck, because there is a runic block in
unicode and fonts that support it outside TeX
https://en.wikipedia.org/wiki/Runic_(Unicode_block).
Did I made any question about unes and unicode??
Don't you see that you not answered eve on my single question or pointed
that some of those questions have some flaws in logic?
How we can discuss if you are ignoring questions adding instead some almost
random comments?
Does Fedora really need to regenerate package with these fonts every
time
when someone will change even single bit in any TeX live resources?
Unanswered question ..
[..]
> If anyone today will need to convert any of those formats to EPS
or PDF
more
> likely will use convert from ImageMagic.
> Isn't it?
From its description this looks like an interface layer, since TeX's
main use is producing pdf and eps it's not particularly surprising it
has one. ImageMagick itself uses ghostscript
Sorry asking. I want to be only sure.
Above it is an answer on my question or ony random comment?
I don't remember name of this TeX package but I'm almost
100%
> sure that it is still in texlive tree somewhere. "The Package"
> generates using metapost cube view with visable only one side,
> two sides and EVEN THREE sides!!! 8-O
> As example of generating some graphics it was obsolete in the
> time when people started using Corel Draw in Win 3.11 era
> (anyone remember this program?).
I don't, but this hypothetical program would be a good example of
literate programming.
This is not hypothetical program. Just found this packaged as rpm.
Look on texlive-threeddice.
You can certainly draw a diagram in Inkscape,
but if you have a large document with lots of these you now have a
directory full of images and their source files, and changing them
means editing these, getting the right one, replacing the included
image. Doing this under source control becomes a real pain. More
concrete example (one I know exists), packages to draw Feynman
diagrams. If you're preparing a professional publication you don't
want to be drawing these by hand.
OMG. Did I ask how can I draw cube/dice?
If yes .. I'm really sorry to distract you.
[..]
> And now back to what I wrote about TeX maintainers.
> TeX live is more like black hole sucking every bit of anything related to
> TeX. Ones something stored in the tree doesn't matter is it still
usefull or
> not still will be "maintained". Those people are thinking that they are
> doing great job but in reality as now TeX live holds probably almost
> everything what was produced as TeX tool/example it shows how small this
> world is.
>
TeX has been around since 1978, so that it hasn't sucked everything in
yet suggests it's not really a black hole. Having put LaTeX to serious
use in the past I've been pretty glad when I've found that a package
or style is available as rpm, because maintaining a TeX install
manually is not pretty.
Hmm. did I ask when TeX development started?
Maybe you don't know but black hole it is not an object which sucks
everything what exists.
It is an object which does not allow escape an object from his own gravity
field. Maybe it is not clear but I;ve used this analogy t point that
packaging an mass all texlive is pure .. <censored>.
Seems you completely lost on what I've been pointing.
Will try to rephrase this as shortly as possible.
TeX live has own pattern of packages. few people now are maintaining
literally in 1:1 mapping those packages into rpm packages.
This is pure nonsense!
One more examples:
TeX packages separately <something> and <something>-doc. Hover rpm can
combine in single package those types of resources because using %doc macro
is possible to specify that some files listed in package are documentation
and by this is possible on install/upgrade stage decide to install/not
install documentation. Only by this is possible to reduce number of
generated packages by more than 2k!!!
This is like trying to package all CPAN packages which is not bad however
what has been done in texlive.spec is similar to packing all perl
extensions/modules automatically. All this without thinking what is
packaged just an mass *everything*, and build all those perl packages from
SINGLE spec file!!!
No one is even trying to do this on perl because people knows that CPAN is
yet another this kind of black hole and qualities some of those modules
varies. More important is that CPAN is enough old (enough old like CTAN)
that you can find in this reo even perl 4 modules which are no longer
useful.
People maintaining packages in Fedora are doing sometimes strange things in
spec files however whatever they've are doing has some reason and they are
fill responsible for what they've done. Generating *blindly few thousands*
packages automatically delegates this responsibility to CTAN. I'm 100% sure
that more than half of those techlive rpm package never been used by anyone.
This way generating as well many nonsenses in texlive package as well.
Only one example (but they are much more like this).
texlive-base package:
Summary : TeX Live filesystem, metadata and licenses shipped in text
form
Description :
TeX Live licenses shipped in text form.
So it contain texts of licenses used texlive packages, /etc/texlive
directory tree and some "metadata". However this is not true because
biggest part of this package are *all directories used by any texlive
package*. In total it is almost 6k directories which should be part of
other texlive packages!!!
In /etc/texlive are subdirectories like dvips, tex and web2c. Why those
directories are not part of other packages? (dvips, web2c ..)
Someone done "brilliant" work doing ths packages generator however whatever
has been generated should be not used blindly in this case. I can imagine
that every texlive package could be generated initially as separated spec
file. After this few people should decide after careful review "ok, I'm
going to take this piece, polish an publish because I see it useful and I'm
signing this using my blood that everything what I've done has some
reason". Every package should be tested somehow at least by maintainer
which looks lke never happen in case of more than 95% of all texlive
packages.
kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
3:55 p.m.
On 2016-10-15, 19:58 GMT, Tomasz Kłoczko wrote:
You are losing the point.
It doesn't matter how and for what I'm using TeX. I've not said even single
word about how I'm using TeX.
Back to the point. Do you have some suggestions what to do? Any
reply to my previous email?
Matěj
--
https://matej.ceplovi.cz/blog/, Jabber: mcepl(a)ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
May you come to the attention of those in authority.
May you find what you are looking for.
May you live in interesting times.
-- claimed to be a Chinese proverb, but its origin is disputed
first documented use
Frederic R. Coudert, Proceedings of the Academy of Political Science, 1939
4:55 p.m.
On 15 October 2016 at 20:58, Tomasz Kłoczko <kloczko.tomasz(a)gmail.com> wrote:
On 15 October 2016 at 12:55, Ian Malone <ibmalone(a)gmail.com>
wrote:
>
> > What was scarry 9 years ago now is even more scary today.
> > Will try to present you what is in texlive today over now available rpm
> > packages.
>
> What exactly are you using TeX for? The following examples suggest you
> aren't very clear on its uses:
You are losing the point.
It doesn't matter how and for what I'm using TeX. I've not said even single
word about how I'm using TeX.
So again: what is the size of cross section of those two sets?
Did I made any question about unes and unicode??
Don't you see that you not answered eve on my single question or pointed
Unanswered question ..
Sorry asking. I want to be only sure.
Above it is an answer on my question or ony random comment?
OMG. Did I ask how can I draw cube/dice?
If yes .. I'm really sorry to distract you.
Hmm. did I ask when TeX development started?
Seems you completely lost on what I've been pointing.
Will try to rephrase this as shortly as possible.
I apologise, I have clearly failed in my obligation to answer every
one of your questions in detail and debate the use and existence of
TeX purely on your terms. Please continue in your campaign to have it
discontinued, I suggest you now write to the people at CTAN, the
creators of TeX Live and Donald Knuth with your concerns, I'm sure
they will all bow to your inexorable logic.
--
imalone
http://ibmalone.blogspot.co.uk
5:38 p.m.
On 2016-10-15, 21:55 GMT, Ian Malone wrote:
I apologise, I have clearly failed in my obligation to answer
every one of your questions in detail and debate the use and
existence of TeX purely on your terms. Please continue in your
campaign to have it discontinued, I suggest you now write to
the people at CTAN, the creators of TeX Live and Donald Knuth
with your concerns, I'm sure they will all bow to your
inexorable logic.
Translated into English: SHOW ME THE CODE! The biggest problem
of TeXLive in Fedora, is that almost nobody does it. There used
to be one Red Hat employee who did a lot of TeXLive maintenance
(not much how much in his free time), but he is gone from Red
Hat and now the main maintainer is spot. He is my hero, but take
a look at the number of packages he maintains (including tiny
ones like Chromium).
So, if you want to take over TeXLive maintenance and break it
into something awesome, I believe the opposition could be
overcame. Long lists of tasks somebody else should do won't
change much, I am afraid.
Best,
Matěj
--
https://matej.ceplovi.cz/blog/, Jabber: mcepl(a)ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
If trains stop at train stations, what happens at work stations?
8:57 a.m.
On 15 October 2016 at 23:38, Matěj Cepl <mcepl(a)cepl.eu> wrote:
On 2016-10-15, 21:55 GMT, Ian Malone wrote:
to be one Red Hat employee who did a lot of TeXLive maintenance
(not much how much in his free time), but he is gone from Red
Hat and now the main maintainer is spot. He is my hero, but take
a look at the number of packages he maintains (including tiny
ones like Chromium).
It's much appreciated!
--
imalone
http://ibmalone.blogspot.co.uk
2:26 a.m.
New subject: <DKIM> Re: Someone needs to stop texlive madness!!!
> Why those vectorised resources are only available as TeX users?
> Why TeX is not prepared to use system wide Type1 font and is not able to
> share those fonts with other applications?
> Why most Type1/TTF fonts are at least served three times as: ghoscript
> fonts, X11/Weyland fonts and TeX fonts?
Separating fonts in application-agnostic packages is indeed the best solution for users,
and the one Fedora packaging guidelines promote. So, feel free to package a couple of
those properly. That will be sufficient to ask TeXLive (and others) maintainers to stop
shipping duplicates.
In the meantime it's quite hard to force people to stop shipping the files they work
with even if those files are an unholy mess.
Regards,
--
Nicolas Mailhot
12:39 p.m.
On Fri, 14 Oct 2016 17:33:00 +0100
Tomasz Kłoczko <kloczko.tomasz(a)gmail.com> wrote:
On 14 October 2016 at 16:02, Kevin Fenzi <kevin(a)scrye.com>
wrote:
> Making personal attacks or calling people names is not acceptable.
>
Did I call someone name? .. hmm ??
Yes, as Adam noted you called people morons. Don't do that.
...snip...
Q: not who accepted this but WHY? Why someone not refused to move
more 5k packages after single build request?
...snip...
If it is true .. maybe can someone help me to understand intention
packaging texlive like it is now?
I can try and provide history here. ;)
Disclaimer: This is just what I remember, it could be wrong.
Texlive is unique. It's very handy and used, especially in the
publishing and educational areas, so it's important to provide it in
Fedora.
There's a number of similarities between texlive and perl's cpan or
pythons pypy. It's a large collection of smaller packages that work
with each other. However, it also has at least one big difference from
those other collections: They do (about) yearly releases of the entire
collection because it's very interrelated. Also, perl and python
communities grew up around their packaging, so there's a large number
of people packaging projects up as they are added. Texlive started as a
free fork of tetex, so it appeared with tons and tons of packages and
no community to package each little part up.
Long ago when texlive was replacing tetex, the first thing that had to
happen was a legal review of all texlive. This took years and lots of
people. Once that was done it got an exception to come in as one source
package and lots of subpackages for all the reasons above. The orig
maintainer had a program that generated the spec file, but they have
long since moved on. Tom has taken over updating it recently and has
done a lot to improve the spec. Yes, there have been bugs or issues,
but sometimes thats the nature of things.
So far this year:
Added lines: 49387 Removed lines: 270572 Total # of lines: -221185
So, Tom has removed 221k lines from there. I think thats a pretty good
tally of improvement.
So, focusing on positive actions here:
* Perhaps we could split things up a little. I have often wondered if
just splitting things in 5-10 packages could help, but I would
absolutely defer to Tom here since he's been doing the work and he
was my sponsor 10 years ago and knows more about packaging than I
ever could.
* If you have specific ideas for improvements, do file bugs and attach
your patches or explain what you think would help. I'm sure he would
love to hear it.
Further than that I would wait for Tom to chime in...
kevin
1:32 p.m.
On Sat, Oct 15, 2016 at 11:39:35AM -0600, Kevin Fenzi wrote:
* Perhaps we could split things up a little. I have often wondered
if
just splitting things in 5-10 packages could help, but I would
absolutely defer to Tom here since he's been doing the work and he
was my sponsor 10 years ago and knows more about packaging than I
ever could.
+1 to all of that.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
12:41 p.m.
On 10/15/2016 08:32 PM, Matthew Miller wrote:
On Sat, Oct 15, 2016 at 11:39:35AM -0600, Kevin Fenzi wrote:
> * Perhaps we could split things up a little. I have often wondered if
> just splitting things in 5-10 packages could help, but I would
> absolutely defer to Tom here since he's been doing the work and he
> was my sponsor 10 years ago and knows more about packaging than I
> ever could.
+1 to all of that.
4 source packages that generate 18 + 11 + 23 + 20 = 72 binary packages
is how debian is packaging it. This seems like a sane middle ground to me.
https://packages.debian.org/search?suite=sid&searchon=sourcenames&...
--
Kalev
3:26 p.m.
On 15 October 2016 at 18:39, Kevin Fenzi <kevin(a)scrye.com> wrote:
[..]
* If you have specific ideas for improvements, do file bugs and
attach
your patches or explain what you think would help. I'm sure he would
love to hear it.
1) Package base texlive binaries with base set of necessary packages
(alphabetically) afm2pl, bbox, cefutils, detex, dvilj, dvips, dviutils,
latex, latex-bibtex, luatex, makeindex, metapost, omega, pdftex, tex4ht.
Maybe few more or less (maybe it would be good to package all dvi related
stuff as single package). Each of those package should be with some
descent/usually used set of additional stuff even if those bits are
maintained as separated texlive package
2) Package something like texlive-devel which will contain whatever is
needed to build other packages (part of it could be set of rpm macros
generating provides/requires dependencies if it is possible)
3) Package *only* what is really need or requested by at last one person
4) do not package PDFs but text dumps of those documentation. Mark those
doc as %doc and include in proper packages. Read at least one time those
dosc because texlive contains many completely random and sometimes wrongly
placed documentation. Do not package documentation about how to
build/install those extensions/packages.
These are 4 very simple points containing as well basic rules of packaging
texlive stuff.
In other words texlive should be similar to areas with php/pecl, perl,
python and few other.
kloczek
--
Tomasz Kłoczko LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
5:08 p.m.
On Sat, 15 Oct 2016 21:26:36 +0100
Tomasz Kłoczko <kloczko.tomasz(a)gmail.com> wrote:
On 15 October 2016 at 18:39, Kevin Fenzi <kevin(a)scrye.com>
wrote:
[..]
> * If you have specific ideas for improvements, do file bugs and
> attach your patches or explain what you think would help. I'm sure
> he would love to hear it.
>
1) Package base texlive binaries with base set of necessary packages
(alphabetically) afm2pl, bbox, cefutils, detex, dvilj, dvips,
dviutils, latex, latex-bibtex, luatex, makeindex, metapost, omega,
pdftex, tex4ht. Maybe few more or less (maybe it would be good to
package all dvi related stuff as single package). Each of those
package should be with some descent/usually used set of additional
stuff even if those bits are maintained as separated texlive package
2) Package something like texlive-devel which will contain whatever is
needed to build other packages (part of it could be set of rpm macros
generating provides/requires dependencies if it is possible)
3) Package *only* what is really need or requested by at last one
person
I don't think thats very practical at this point. We don't have any way
of knowing how much any given package is used. Some people would of
course file bugs or otherwise ask for whatever package back, but many
more would just say 'man, things are busted now, I'll go to
$otherdistro where it works'. Additionally some people wouldn't know
exactly what packages would be missing up front (This thing that used
to work doesn't anymore, it could be these 100 packages).
4) do not package PDFs but text dumps of those documentation. Mark
those doc as %doc and include in proper packages. Read at least one
time those dosc because texlive contains many completely random and
sometimes wrongly placed documentation. Do not package documentation
about how to build/install those extensions/packages.
text dumps of pdf are often pretty horrible. Formatting is lost, etc.
kevin
12:15 p.m.
On Sat, Oct 15, 2016 at 09:26:36PM +0100, Tomasz Kłoczko wrote:
3) Package *only* what is really need or requested by at last one
person
What exactly is the *harm* in having things you are not using packaged
in Fedora? How does it affect you (or any other user of Fedora) if the
number of people using a package is five, one, or zero?
These are 4 very simple points containing as well basic rules of
packaging
texlive stuff.
In other words texlive should be similar to areas with php/pecl, perl,
python and few other.
It would be excellent if we could easily provide 100% of the package
archives for those languages to users.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
3:48 a.m.
On 10/16/2016 07:15 PM, Matthew Miller wrote:
On Sat, Oct 15, 2016 at 09:26:36PM +0100, Tomasz Kłoczko wrote:
> 3) Package *only* what is really need or requested by at last one person
What exactly is the *harm* in having things you are not using packaged
in Fedora? How does it affect you (or any other user of Fedora) if the
number of people using a package is five, one, or zero?
“dnf update” takes longer to download package list and uses more of your
bandwidth quota.
Florian
7:28 a.m.
On Mon, Oct 17, 2016 at 10:48:54AM +0200, Florian Weimer wrote:
>>3) Package *only* what is really need or requested by at last
one person
>What exactly is the *harm* in having things you are not using packaged
>in Fedora? How does it affect you (or any other user of Fedora) if the
>number of people using a package is five, one, or zero?
“dnf update” takes longer to download package list and uses more of
your bandwidth quota.
But that's true for me for thousands of packages I don't use, and
whether or not someone uses them doesn't change that. I agree that this
is a scaling problem we have (it's particular evident when installing
packages into a minimal cloud image or a docker container!), but I
don't think "don't scale, then!" is the answer.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
7:44 a.m.
On Mon, Oct 17, 2016 at 5:28 AM, Matthew Miller <mattdm(a)fedoraproject.org>
wrote:
On Mon, Oct 17, 2016 at 10:48:54AM +0200, Florian Weimer wrote:
> >>3) Package *only* what is really need or requested by at last one
person
> >What exactly is the *harm* in having things you are not using packaged
> >in Fedora? How does it affect you (or any other user of Fedora) if the
> >number of people using a package is five, one, or zero?
> “dnf update” takes longer to download package list and uses more of
> your bandwidth quota.
But that's true for me for thousands of packages I don't use, and
whether or not someone uses them doesn't change that. I agree that this
is a scaling problem we have (it's particular evident when installing
packages into a minimal cloud image or a docker container!), but I
don't think "don't scale, then!" is the answer.
Well, I believe we've drifted from the original point which implied some
type of test to determine
if a package was being used before it was included in the repository ---
which is akin to the chicken and the egg - if it's not there it isn't going
to be used.
The last thing we need is to discourage new packages, I believe for obvious
reasons.
As far as "takes longer" and "bandwidth usage" - we're talking
about
metadata here - and the impact
would be trivial. In any event, the advantages to the Fedora community of
having a large, robust
package repository would outweigh any increase in time or bandwidth
required to support the metadata.
There already was a thread regarding dnf and deltarpm which covered most of
this.
11:04 a.m.
2016-10-15 14:39 GMT-03:00 Kevin Fenzi <kevin(a)scrye.com>:
On Fri, 14 Oct 2016 17:33:00 +0100
> If it is true .. maybe can someone help me to understand
intention
> packaging texlive like it is now?
I can try and provide history here. ;)
Disclaimer: This is just what I remember, it could be wrong.
Texlive is unique. It's very handy and used, especially in the
publishing and educational areas, so it's important to provide it in
Fedora.
There is a way to package texlive in small packages, using
few resources, etc. But you need to create like 3k packages
to bootstrap, the *really* hard part, then, create and retire like
2 to 8 per month.
There's a number of similarities between texlive and perl's
cpan or
pythons pypy. It's a large collection of smaller packages that work
with each other. However, it also has at least one big difference from
those other collections: They do (about) yearly releases of the entire
collection because it's very interrelated. Also, perl and python
communities grew up around their packaging, so there's a large number
of people packaging projects up as they are added. Texlive started as a
free fork of tetex, so it appeared with tons and tons of packages and
no community to package each little part up.
Thats the big problem, or maybe an advantage if mapping rpm
meta packages to texlive meta packages.
Long ago when texlive was replacing tetex, the first thing that had
to
happen was a legal review of all texlive. This took years and lots of
people. Once that was done it got an exception to come in as one source
package and lots of subpackages for all the reasons above. The orig
maintainer had a program that generated the spec file, but they have
long since moved on. Tom has taken over updating it recently and has
done a lot to improve the spec. Yes, there have been bugs or issues,
but sometimes thats the nature of things.
So far this year:
Added lines: 49387 Removed lines: 270572 Total # of lines: -221185
So, Tom has removed 221k lines from there. I think thats a pretty good
tally of improvement.
So, focusing on positive actions here:
* Perhaps we could split things up a little. I have often wondered if
just splitting things in 5-10 packages could help, but I would
absolutely defer to Tom here since he's been doing the work and he
was my sponsor 10 years ago and knows more about packaging than I
ever could.
* If you have specific ideas for improvements, do file bugs and attach
your patches or explain what you think would help. I'm sure he would
love to hear it.
Further than that I would wait for Tom to chime in...
I talked a bit about at some point in the past, but I am currently
not very active contributing to openmandriva, where I did make a
1 to 1 rpm to texlive package, extraced %post scriptlets from
texlive installer, etc.
https://lists.fedoraproject.org/pipermail/devel/2015-March/209458.html
The post script was a bit weird tough, it did run in background,
wait 15 secs, if some new texlive package was installed, wait
more 15 secs, and so on, and then, in background do the
update:
https://abf.rosalinux.ru/openmandriva/texlive-tlpkg/blob/master/texlive.post
I even wrote a graphics texlive tool to install new packages or
update texlive:
https://abf.rosalinux.ru/openmandriva/texlive-tlpkg/blob/master/tlmgr
that would use Mandriva urpm for actually managing the packages,
and look like this screenshot...
https://www.tug.org/texlive/doc/texlive-en/texlive-en.html#tlmgr
The above might look like some self-promotion, maybe it is :)
but just to give an idea of a possible approach to handle it
differently.
Thanks,
Paulo
3:27 a.m.
On 2016-10-14, 23:03 GMT, Tomasz Kłoczko wrote:
Probably more than 50% (if not more than 80%) of the TeX live
is like this. Most of the resources should be archived and
preserved for next generation cyber archeologist however now
they should not be served as regular rpm packages because it
will make look Fedora stupid ("who is more stupid? someone who
is stupid or someone else who follows stupid one?").
Aside from calling people names (yes, don't do it!), this is
obviously a case of SPEC generated by a script. I guess we just
pull to Fedora whole TeXLive. So,
a) whatever you think about the quality of packages included,
the morons are not Fedora maintainers, but you have to target
your ire upstream, OR
b) you should sit down and propose and make TeXLive
maintainers/users some mechanism how to choose and select only
relevant package. To know which packages are relevant is however
quite tricky. I would tend to agree with you that the ones you
mentioned are probably obsolete, but it is really hard to
decide. My wife relies desperately on linguex (and its dependend
packages, e.g. cgloss4e)? Would you know whether it is relevant
or not?
Best,
Matěj
--
https://matej.ceplovi.cz/blog/, Jabber: mcepl(a)ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
Of all tyrannies, a tyranny exercised for the good of its
victims may be the most oppressive. It may be better to live
under robber barons than under omnipotent moral busybodies. The
robber baron's cruelty may sometimes sleep, his cupidity may at
some point be satiated; but those who torment us for our own
good will torment us without end, for they do so with the
approval of their consciences.
-- C. S. Lewis
2762
days inactive
2766
days old
23 comments
11 participants
participants (11)
-
Adam Williamson -
Florian Weimer -
Gerald B. Cox -
Ian Malone -
Kalev Lember -
Kevin Fenzi -
Matthew Miller -
Matěj Cepl -
Nicolas Mailhot -
Paulo César Pereira de Andrade -
Tomasz Kłoczko