Upgrade failure and corrupted installation ?

[Norbert Preining]

Hi Yann,

> > - restore the original (small) tlpdb (you made a backup copy before
> >    overwriting it, didn't you?)
> 
> Yes.

Good.

> I am not sure about that : tlmgr update --list --all
> --reinstall-forcibly-removed

You added the --list, don't do that.

> But I have a laptop with roughly the same texlive 2023 installation, and I
> updated it in July, so I could take the tlpdb from there and do a regular
> update, could I not ?

No, the tlpdb records which packages are installed. If you do that it might look
like you have packages installed but the actual files are missing.

> Regarding your explanations about what happened earlier, is it not a design
> problem in tlmgr update that interrupting it causes data loss ? I mean,
> downloading updates can go wrong for a variety of reasons, and laptop
> battery can go out too.

It happens very rarely, we already try to ensure that writes are done on a
per package basis, and fs are synced afterwards. Having a completely safe
against interrupts implementation would be nice, but would require developing
some journaling for tlmgr operations, which we don't have.

> Debian's apt first downloads all the required packages, and then actually
> does the upgrades. It is completely safe to interrupt it in the first phase.

But not in the second phase.

> Furthermore, I think the local database is managed in a more failure-safe
> way ; even with failures in the second phase, I always found a way to get
> back on my feet.

Debian only supports Linux. That is trivial.
We support Windows, Mac, Linux, BSD, AIX, Solaris, ....

> It seems the tlpdb contains information about which packages and revisions
> are installed, as well as information like the description, what files are
> part of it, etc.

Yes, it is designed similar to Debian's package index.

> The latter can be retrieved from a CTAN mirror, but the former is inherently
> specific to a particular texlive installation.

Not the files itself, but the packages.

> Would it not be a good a idea to split that big file in two, and treat the
> (much smaller) file about what is installed and what is about to be upgraded
> more conservatively ? Such a file should be small enough that keeping its
> successives versions, or, say, its last 10 versions, (and therefore : not
> overwriting it during an upgrade) would be feasible.

I am not sure how that should work practically. We would still need to know
which operation was being done and whether it succeeded, and have some
rewind/check procedure.

Feel free to look into the Perl code, the writing code for tlpdb is very
much localized to TLPDB.pm, maybe you can come up with some good ideas.

We *could* split the tlpdb or create a "user-facing tlpdb" variant that
only contains the package names, package versions, but also the
depends (for dependency tracking).

OTOH, that would make searching (tlmgr search) much more useless, ...

So I am not sure if it is worth the pain to split.

OTOH, doing some more safety measures if possible, I am more than open
to suggestions.

All the best

Norbert

--
PREINING Norbert                              https://www.preining.info
Mercari Inc.     +     IFMGA Guide     +     TU Wien     +     TeX Live
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13