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
Received on Fri Jan 02 2015 - 08:53:59 UTC