[tex-live] tlmgr and command interface

[T T]

On 30/07/2009, Roberto Giacomelli <giaconet.mailbox at gmail.com> wrote:
> Ok, this morning only texlive.infra can be update well then I ask to
> tlmgr the installation of the new version:
>>tlmgr update texlive.infra

We will not support this behaviour any more.

> tlmgr: installation location http://texlive.guiling.fr
> tlmgr update: please specify a list of packages or --all.

There will be clearer message after the round of patches (in a day or two).

> Ops, the command failed because now the infrastructure update take a
> new option --self:

Yes, this option will be now mandatory for infrastructure updates.

> Finish. But... writing >tlmgr update texlive.infra show very clearly
> what I want.

Yes, but we won't allow for that any more, sorry.

There is a good reason for that: we cannot guarantee that tlmgr will
be still operational after the update if we allow for cherry-picking
updates to infrastructure packages. Therefore, either *all* or *none*
of infrastructure packages have to be updated.

> The option --system is more clear and general than --self. But a

It is not clear to me. You cannot be sure what it means unless you are
given further context. I think that --self is much more intuitive and
implies better that you want the TeX Live Manager (tlmgr) to update
itself.

> command >tlmgr update texlive.infra must be equivalent to the command
>>tlmgr update --system.

See above. Also, to allow for

  tlmgr update texlive.infra foo bar ...

we would need extra checks in the code to make sure we get *all*
infrastructure updates this way and abort otherwise. More code and
special cases mean more potential bugs, so there must be a good reason
to add them, especially for critical tasks. Also, infrastructure
updates carry more risk as compared to regular updates and explicit
--self should make users more allert to that fact.

The concept that I can specify the module to
> update remaning the same.
> In general the update process I think can be based on this rules:
> the key update can be follow by
> 1 - the option --all (first tlmgr provide eventually system update and
> after the remain package updates);

As I explained above, we want to alert users to infra updates, so
making them look as regular updates is not a good idea IMO.

> 2 - the option --system (only eventually system update will be performed);
> 3 - the option --package (only package updates are performed (not system));

You get this with --all. Also, --package might might confuse some
people that collections will not be updated.

> 4 - the option --interactive (tlmgr show the list of update items and
> waiting for a user input);

Well, there is already an interactive GUI, so I'm not entirely
convinced about this concept, but see also below.

> 5 - a list of module update (system or not).
>
> Usually I want to see the list of updates, so I can first run a tlmgr
> update --list and after a tlmgr update --all. This is the reason
> because I desire an assembly unique procedure: the interactive option.

And what's wrong with calling tlmgr twice:

  tlmgr update --list
  tlmgr update foo bar  ...

The only problem I see is when there are lots of packages and you want
to skip only a few of them, so something like this would be useful:

  tlmgr update --all --except baz qux ...

Thanks for your suggestions. We will think about them, but I'm afraid
that any major changes to the option system will not be possible at
this late stage. This could wreak havoc in our code base, and
significantly delay the release.

Cheers,

Tomek