(In reply to Johannes Segitz from comment #0)
> I noticed today on my transactional tumbleweed install that LaTeX is broken.
> This is caused by the way transactional-update works. All these files:
> find /var/lib/texmf/ -type f
> vanish upon reboot.
> 
> This means this will also not work on ALP. I CC'd the transactional-update
> maintainer, because ATM I don't know what the proper location would be

A read/write /var/lib/texmf/ is a must have for TeXLive and all its engines as well as data libraries like locations and fonts.  This is true for all data below /var/ and /var/lib/ ... there are more packages which depends on that.

Like data bases, caches, mail and uucp spools, and many more.

Who is responsible for this behaviour brake?

Wasn't the whole idea behind /var that it is supposed to be read-write and, more importantly, persistent, unlike /tmp which can be gone upon the next reboot? Hence /var/tmp vs. /tmp ?

The problem here is that /var is not mounted during an update (because that would directly influence the currently running system). On a transactional system the RPM packages must not (and on regular systems should not) install files into /var or modify files in /var via scripts, see https://en.opensuse.org/openSUSE:Packaging_for_transactional-updates#Files_in_/var.

Before I continue let me clarify: /var is read-writeable, and of course it is persistent! The files are not gone either: they are part of the snapshot, but they are shadowed by the actual /var mount in the live system.

So how to solve this? From what I've seen (though the TeX Live packaging is quite complex and I probably didn't see everything) it should be possible to call the scripts currently triggered by RPM scripts via a systemd service during boot instead.

That sounds an awful lot like a comeback of old SUSEconfig and $YAST_IS_RUNNING to postpone post-install actions. That was a neverending cause of trouble until we finally got rid of it many years ago.

Rather than turning back the clock and reintroduce things like SUSEconfig etc., how about using an overlay filesystem for /var during that update? Of course the changes would have to be written to the real target (snapshot?) after the packages are updated. Just a weird, fuzzy idea.

(In reply to Ignaz Forster from comment #3)
> The problem here is that /var is not mounted during an update (because that
> would directly influence the currently running system). On a transactional
> system the RPM packages must not (and on regular systems should not) install
> files into /var or modify files in /var via scripts, see
> https://en.opensuse.org/openSUSE:Packaging_for_transactional-
> updates#Files_in_/var.

Ouch ... does this mean that every package using /var is broken by default? This is a problem ... run on a standard system (not alp) as root the command:

 find /var -exec rpm -qf '{}' \+ | grep -vE 'filesystem|owned' | sort -u

I count on my Tumbleweed 85 packages for /var ... in other words the approach
above is broken by its own definition.

> 
> Before I continue let me clarify: /var is read-writeable, and of course it
> is persistent! The files are not gone either: they are part of the snapshot,
> but they are shadowed by the actual /var mount in the live system.
> 
> So how to solve this? From what I've seen (though the TeX Live packaging is
> quite complex and I probably didn't see everything) it should be possible to
> call the scripts currently triggered by RPM scripts via a systemd service
> during boot instead.

Beside this FHS is old yes but nevertheless used today

https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#purpose31
https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#varlibVariableStateInformation

(In reply to Dr. Werner Fink from comment #6)
> (In reply to Ignaz Forster from comment #3)
> > The problem here is that /var is not mounted during an update (because that
> > would directly influence the currently running system). On a transactional
> > system the RPM packages must not (and on regular systems should not) install
> > files into /var or modify files in /var via scripts, see
> > https://en.opensuse.org/openSUSE:Packaging_for_transactional-
> > updates#Files_in_/var.

I see

 openSUSE:Packaging for transactional
 Jump to: navigation, search
 Can't find what you are looking for?

looks like an transactional update ;)

(In reply to Dr. Werner Fink from comment #8)
> (In reply to Dr. Werner Fink from comment #6)
> > (In reply to Ignaz Forster from comment #3)
> > > The problem here is that /var is not mounted during an update (because that
> > > would directly influence the currently running system). On a transactional
> > > system the RPM packages must not (and on regular systems should not) install
> > > files into /var or modify files in /var via scripts, see
> > > https://en.opensuse.org/openSUSE:Packaging_for_transactional-
> > > updates#Files_in_/var.
> 
> I see
> 
>  openSUSE:Packaging for transactional
>  Jump to: navigation, search
>  Can't find what you are looking for?
> 
> looks like an transactional update ;)

Broken due to the citation ...

Is there a working solution without systemd/systemd-tmpfiles as TeXLive has to work even in the build system (obs/ibs) for technical documentation of various packages.

We had a discussion about how to solve this today. We came to the following conclusions:

* TeX Live is required as a build dependency, so should not have a systemd dependency for that.
* The script to populate the files in /var/lib/texmf (which is currently called during %postrans) can take several minutes to finish, so calling it during boot instead is not a good idea.
* To avoid unnecessary runs the script uses flag files to check whether it has to run.
* Even on traditional systems the files generated in /var/lib/texmf may not match the installed files, most prominently on a rollback.

This may be solved by the following ideas:
* The script in %posttrans could check for the TRANSACTIONAL_UPDATE environment variable; if it is there, /usr/share/texmf/texconfig/update (and any other parts which write to /var) will not be called. This is optional, but it would save the space for the invisible databases and avoid the shadowed directory warning at the end of the transactional-update run.
* A systemd service at boot time will call the script instead. On traditional systems and if there was no update of texlive packages the script won't do anything (see the flag file mechanism to prevent unnecessary runs above). If someone really installs texlive into the root file system of a transactional system (instead of a container or toolbox), then that person will have a delayed system boot, but it is working at least. The flag files would need to be changed to be put into /etc however to survive the system reboot.
* If an additional flag file is introduced, the script could also detect the rollback case and regenerate the files.

This is an autogenerated message for OBS integration:
This bug (1211613) was mentioned in
https://build.opensuse.org/request/show/1088858 Factory / texlive-filesystem

I discussed this with Ignaz briefly yesterday. Thanks for providing a fix.

And btw. I'm a maintainer of a package that has a similar problem, so I feel the pain too ;)

This is an autogenerated message for OBS integration:
This bug (1211613) was mentioned in
https://build.opensuse.org/request/show/1089013 Factory / texlive-filesystem

Even if this behaviour is now fixed with the accpepted SR#1089013 ... I'd like to propose a view thoughts.  One proposal would be a localtion for temporary scriptlets which would a) survive a reboot and b) be called after the reboot and the marked as done or simply be removed from the queue of jobs doable after reboot.  The other proposal would be to store for a package the file tree of /var during the transactional update in an cpio/tar archive to be able to apply this after the next reboot if accessible