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
Received on Wed Oct 14 2015 - 17:39:58 UTC