[tex-live] Tool update outside tlmgr

[Paulo Roberto Massa Cereda]

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