>You have prompted me to fill in a long-standing dangling hyperlink.
>
>* http://jdebp.eu./FGA/slashpackage.html
If I may add my two cents: I think you're mixing two very different
things in this page.
There is the slashpackage convention for installed packages, i.e.
visibility of executables in /package/category/name/command/name
and the like. I find it useful; and my software *still follows* that
convention, if compiled with --enable-slashpackage.
And there is the internal structure for building packages, which is
package/compile, package/run, etc. I liked its simplicity at first,
but with experience, I found that it wasn't ideal.
The primary issue is that it's inherently not cross-compile-friendly.
Having a pre-written compilation script makes it difficult to separate
gathering information about the target and actually building for the
target; whereas a configure/make system can frontload the data
gathering operation. (And in my case I frontload it all in the
skalibs package, so when the annoying part of finding correct sysdeps
for the target has been done once, all the rest of the software
cross-compiles effortlessly.)
A secondary issue is that system administrators and distribution
packagers, i.e. the intended users of the build system, just could
not stop complaining about it, to the point that complaints about the
build system were for some time the majority of the mailing-list's
traffic. No matter whether their reasons were good or bad, if the
intended users of an interface don't like the interface, then it's
probably a good idea to change the interface. Since switching to
configure/make, the popularity of s6 has skyrocketed; I don't think
it's entirely accidental.
So yes, the internal package/compile build system is something I
stepped away from. But IMO that's not at all the important part of
the "slashpackage convention", one does not imply the other; and
I wish you would emphasize that.
--
Laurent
Received on Tue Jan 16 2018 - 15:44:03 UTC