[tex-live] Tool update outside tlmgr
Paulo Roberto Massa Cereda
cereda.paulo at gmail.com
Tue Dec 8 20:39:05 CET 2015
Hello, friends,
Thank you very much for your feedback on my humble question.
RK:
> though you can convince tlmgr to install files from external
> repositories, I strongly recommend to put everything on CTAN.
Agreed, this is indeed the best approach. To be honest, I was too much
focused on TeX Live and forgot about CTAN.
NB:
> I would STRONGLY oppose that. Software such as TeX Live should NEVER
> need root access to install. Instead, it should be installed and
> owned by the user of a single-user machine, or the administrator(s) of
> a shared machine, or better, by a special unprivileged account
> accessible to the owner/administrator.
You are right, Nelson. I think TL is the only software installed as root
in my machine, mostly because I like the default scheme. But since it
does not required a root install, I should've put it inside /opt.
Anyway, running arara with privileged access would be terrible indeed,
as it would grant an untrusted tool unrestricted access to the entire
system.
> Root privileges are extremely dangerous when foreign software is run.
> The recent BitLocker-like attack on GNU/Linux systems (wherein files
> in all filesystems are encrypted and held for ransom by the attackers)
> propagated successfully because a Web utility foolishly demanded root
> access to run. Software should always run with minimal privileges:
> there is a good reason that modern Web browsers and Java try to
> sandbox program execution.
Indeed. One of the complaints I get a lot with arara is the lack of
chained commands. The reason is quite simple: Java sandboxes the
execution and disallows this sort of trickery. :)
NP:
> thanks for contacting us in advance, always a good idea!
My pleasure, I like to pester you guys. :)
> Of course you are free to implement such a feature, but I ask you
> - in the similar vein as Reinhard - to consider simply uploading
> new minor versions to CTAN (say 5.0.1, 5.0.2 etc).
Yes, this is indeed a great plan.
> Do you expect that rules change on a daily basis? My guess is that
> rules will change rather rarely, probably less than the usual
> user will use updates via tlmgr or the MikTeX equivalent.
You are right, rules won't change that much, unless Marco Daniel goes on
a rule editing spree. :) On a second thought, this new feature might
cause more trouble than benefit.
> Not really a problem. tlmgr does not keep md5 sums of the files.
> If there is an update to arara in TeX Live, and one of the files/rules
> got *missing* during an --update-rules operation, tlmgr will mention
> this with a warning, but happily continues.
Oh no, my OCD will certainly not like these warnings. :) Thanks for
confirming the default TL behaviour.
> But then you might come into vesion squeeze hell: Consider this
> series of actions:
>
> - user installs arara with rules v.1
> - user updates arara rules with --update-rules to v.2
> - texlive provides and update
> - user installs arara and receives rules v.3
>
> How would arara handle that? WOuld it chekc version numbes in one way
> or another?
Somehow, yes. :) If rule updates were deployed in the user space (say,
inside $HOME/.arara), arara would always favour this location instead of
the default path (the default install). But then rules should have to be
always updated via --update-rules, as the path lookup would ignore the
default rule set, even if tlmgr has updated arara to the newest rules.
Oh my, it looks complicated. Let's scratch that, shall we? :)
> This is the problem we faced/facing in TeX Live with generated font
> map information (running updmap), and it is a *great* pain.
I can see why. :)
> IMNSHO I believe the best would be to go via CTAN updates. If you want
> to keep rules and program versions separate, you could even upload
> a package called 'arara-rules' to CTAN, separate from arara, and then
> only update arara-rules (version could be time stamps eg) on CTAN.
CTAN it is. :)
> If you want to have --update-rules in parallel, then it might be
> better to update in place, instead of system-user splitting, die
> to version squeeze hell, as explained above.
Indeed.
UF:
> miktex tracks files. I don't know the details, but it sometimes
> want to "repair" a package when I changed a file during some
> debugging.
Good to know. Let us see if I finally manage to pack arara for MiKTeX,
it is an old dream. :)
All the best!
Paulo
More information about the tex-live
mailing list