On 14/10/2015 18:47, Buck Evan wrote:
I have a pretty extensive test suite for my system that's built atop s6, and the only part that explodes is the access of leapseconds.dat
What about access to libexec binaries such as s6lockd-helper or s6-rc-oneshot-run? Try running s6-setlock with the -t option: does it work? (Use the latest git head, previous versions won't be accurate)
This feels counter to the "allstatic" strategy that s6 uses by default. Would you be opposed to converting the leapseconds.dat to a .c format during the build, and statically linking it?
Since the current leapsecs.dat deployment mechanism is "use the latest skalibs release" anyway, that's not a bad idea at all, and would definitely simplify things for users - I'll probably do it, thanks for the suggestion. However, this is but one specific instance, and I cannot guarantee that skalibs, or any other package, will never want to install files in /etc or something. The software I write assumes it knows where it's installed, and it's a very big assumption; doing otherwise would require, for instance, reading a prefix in an environment variable at the start of virtually every binary, which would be a big change and a significant security concern, as well as a non-negligible performance impact. Even if I make it work for leapsecs.dat, I believe it still breaks in other places - namely, everything that uses libexec binaries - and save for exporting every binary, which would be ugly as hell, I don't see an easy way to fix that. Run-time prefixing is manageable with dynamic libraries, with PATH, with specifically designed runtimes such as Python, but it's just not doable in the general case, and it seems to me you're trying to cram a square peg into a round hole here. -- Laurent
