Hi Paul,
(Sorry if this appears multiple times--I think my first message was blocked due to a non-subscribed envelope sender.)
If you wish to have an additional envelope sender that can post, you can send it to me, as you did for the supervision list.
I think a small change that would make toki a bit happier would be this: don't insert "/usr" into the default installation paths when the prefix is something other than "/".
I thought about doing it this way, and I agree that the /usr part is a nuisance when users specify a prefix, but my idea was consistency over magic. I hate magic: it breaks the principle of least surprise. In this case, however, maybe expectations are to have something convenient, which is more aligned with magic than with logic. So I'll probably try to do as you suggest.
The documentation for --enable-slashpackage could describe the values it sets for dynlibdir, libdir, includedir, and sysdepdir, and should call out the fact that datadir still defaults to /etc. (E.g., if you're installing as a non-root user in your home directory with --enable-slashpackage=$HOME, you'll also need to set --datadir.) More generally, it might be helpful to say what to expect if you set both --prefix=/foo and --enable-slashpackage=/bar.
Good points. I will document more.
Since you're departing from slashpackage by default, how would you recommend that dependent packages find the skalibs files? Before, I had a single configuration parameter in my packages for the skalibs prefix, which defaulted to /package/prog/skalibs, and then I would find /include and /library within it.
This is embarrassing, but I really don't have a recommendation. The thing is, "where to find the files I depend on ?" is a system-wide policy decision, not a package-wide policy decision, and I do not want to enforce system-wide policy in a package. I've done it before and it's not a good idea. This is one of the reasons why I dislike the pkg-config approach: using the pkg-config format in a package practically forces the user to deploy the pkg-config tool. As an admin, it annoys me to no end when software tells me what tool I should use to manage it. I believe that the system-wide database of package locations should be totally independent from the software itself. It should be managed by the admin, or the distribution's package manager. I believe it is pretty much the core of a distribution's job to make consistent system-wide policy choices and provide the admin with tools to maintain the package database; and as a software author, the best thing I can do is stay out of the way and not try to be smart. I still provide specific support for slashpackage because knowing that it will be installed according to that convention allows software to make stronger assumptions and be more robust; but that's pretty much the only reason. So, in short, the user is the only one who knows where the skalibs files have been installed, so the user is the only one who can tell dependent software where to find them. I cannot help there. If/when skarnet.org software gets packaged, finding the files in an easy and consistent way is the main value that a distribution can provide.
What do you think about replacing --enable-right-tz with a runtime check?
Runtime checks are a slippery slope. One is harmless, but once you have a precedent, you can easily end up autodetecting your whole system everytime you exec a binary. Given my love of chain loading, I try to avoid going down that road. :) However, since timezones are a process-wide setting (which is debatable in itself, and what is unarguably broken is to have leap second handling part of a process-wide setting), it makes sense to detect the timezone type at run time indeed - so I will probably go with your suggestion. It's bugware, but with a broken standard, there's no avoiding it.
Using that check at configure time might also be useful to autodetect --enable-tai-clock.
Compile-time feature autodetection is dangerous. It assumes that the build machine is the same as the host machine, which may not be true; and host-wide features can't be added to sysdeps, which only gathers arch-wide features. I'd much rather have users keep specifying host-wide features manually. (Or maybe sysdeps should be split into archdeps and hostdeps ? Ew.) -- Laurent