This one seems to be responsible for quite some weird fallouts - likely some configure scripts now no longer find one of the files they are looking for (as update-ca-certificates -f no longer runs on the build system)

See for example build fails of

docker
mono-core
libqca2
libqca-qt5

CC @kukuk who made the change; the build system is not systemd managed and has does not fire the services (init=/.build/build)

The best course might be to still call update-ca-certificates if -f /.buildenv

I'd rather go for something like test -w /var/lib/ca-certificates

Dominique Leuenberger (dimstar) - almost 7 years ago

reviewer

Sounds like a reasonable option too; but that would mean on a running system with the service enabled, it is running twice: in the post script and then triggered by the service again

---

Ludwig Nussel (lnussel) - almost 7 years ago

author source maintainer

yes and no. If no ca-certificates change the service wouldn't trigger and even if it would most hook script won't regenerate their output. That's why the %post calls update-ca-certificates with the -f option to force regenerate all output files.

Thorsten Kukuk (kukuk) - almost 7 years ago

Hm, /var/lib/ca-certificates is always writeable if we update ca-certificates, even in transactional-update case. But the result may not be correct, since not all certificates are accessible (/etc).

---

Dominique Leuenberger (dimstar) - almost 7 years ago

reviewer

But those would be corrected on next boot, when the oneshot service comes up and re-generates the files, no? (and reboot is needed for transactional updates in any case)

or we add that test directly to update-ca-certificates

Any consensus on the way forward here?

Thorsten Kukuk (kukuk) - almost 7 years ago

Yes, see bsc#1045942, transactional-update has the needed changes in Factory, waiting for Ludwig.

Backlog, until a fix can be prepared to not break build system setups