On 15/10/2015 02:02, Buck Evan wrote:
> Are you idealogically opposed to the relpath strategy?
> Under this scheme, no absolute paths would be encoded in any binary, only
> relative paths.
I'm not ideologically opposed to the relpath strategy, I don't *hate*
it, but I think it has important drawbacks that prevent it from being
an acceptable fit for skarnet.org software.
- Going all relative is a pretty intrusive policy decision. Since you
can't rely on installation paths such as /bin and /libexec, in order
to ensure consistency of your intra-package dependencies, you basically
have to reserve a whole hierarchy to place all your stuff - binaries,
libexecs, data, you name it, it needs to be available in a place you
can find by just the location of the current binary. So, you can say
goodbye to old-fashioned installations with /bin and friends: it's
everything under a subtree, à la slashpackage but without the benefits
of guaranteed absolute paths, and no /command. Which means the more
packages you install this way, the more "interesting" your PATH becomes,
unless you have a single entry point to link to /bin (like gcc).
It's a fundamentally different approach from run-time locations that
are known at compile-time; and it requires specific support. And either
you design your package that way univocally, and you end up with
software that has an even more annoying installation policy than
slashpackage (which is the very reason why slashpackage didn't catch,
to my dismay); or you make it a compile-time option, and that option
has consequences in the form of #ifdefs in all your binaries, which has
an important maintainability cost (and is unfathomably ugly).
- You thought you had it easy with intra-package dependencies? Then
try *inter*-package dependencies. If you depend on a piece of some
other package that is not handled by an ad-hoc mechanism (dynamic linker
configuration for shared libs, PATH for exported binaries), then it's
basically impossible to find it unless your installation system supports
that case, and even then you need to add hooks to your code to make it
work: more ad-hoc ugliness.
- Nit, but still worth mentioning: having to getcwd() in every binary
that has a dependency can get old real fast. It's not only the getcwd,
it's that the getcwd() interface can fail and either you allocate
PATH_MAX bytes for it, or you bring in malloc() and dynamic string
management functions. For heavy stuff like gcc, that's completely
negligible, but for small binaries designed for intensive chain loading,
such as execline programs, this may be a significant relative cost.
- Finally, a personal taste: I don't like depending on the value of
argv[0]. It's useful for very special cases such as busybox, but in
the general case, I don't think a program should act differently
depending on the way the binary is named or located. I want users to
be able to link binaries anywhere and call them however they want.
With the relpath strategy, this is simply not possible: in order to
access the rest of its package's data, a binary has to be very
precisely located inside its package, and cannot be called as an
external link. Paradoxically, not knowing your installation path
at compile-time enforces *stricter* location constraints on the
binaries!
Conclusion: the "all relative" policy works, it's used with
success by gcc and probably other packages I'm not thinking of,
but it's not something to take lightly, it requires designing the
software around the policy, which I don't like, and it's definitely
not suited to skarnet.org packages - so I'm not going to go the
extra mile to accommodate it.
--
Laurent
Received on Thu Oct 15 2015 - 01:45:42 UTC