Re: [Nmh-workers] 1.7's `make clean' is Overzealous.

[Ken Hornstein]

>> Weeell, I was talking about sysconfdir.
>
>Where do the GNU coding standards say not to put stuff in our own
>directory for sysconfdir?  I don't see anything under the
>sysconfdir description itself:  certainly no indication that it's
>wrong.  In contrast, see the quote that Ralph has posted.

I didn't say that the standards said to NOT put sysconfdir files under a
subdirectory; my point was just that unlike, say, libexecdir, it doesn't
say that you SHOULD put it under a directory.  Yes, it does say at the
end of that section that it "might be useful" to group a large number
of files into a subdirectory.  I would suggest that means, "it's up to
you".

>> We can't re-litigate decisions?  Since when?
>
>I did not say we can't.  It would make for a more complex discussion
>in this case.

Fair enough; I would humbly suggest maybe this one is overdue.

>> Like I said, I only have a beef with sysconfdir; I'm fine with a
>> hardcoded appending for libexecdir.
>
>Different support for libexecdir and sysconfdir is confusing, I
>think.  And I see no reason for it.

Well, fair enough ... but at least one package you mentioned (sudo)
seems to do exactly that.  They install files in $(libexecdir)/sudo and
$(sysconfdir).  I don't really have a handle on what different packages
do.  In fairness, I did find that at least one package (auditd) did
install files in $(sysconfdir)/audit, but it was using $(sysconfdir) as
the basis to install things outside of it's "normal" configuration space
like startup scripts; I'm not sure that's a realistic example.

Oh, an additional wrinkle: openldap does:

ldap_subdir="/openldap"
AC_ARG_WITH(subdir,
[  --with-subdir=DIR       change default subdirectory used for installs]

And in their build system they do:

ldap_subdir = @ldap_subdir@

datadir = @address@hidden(ldap_subdir)
moduledir = @address@hidden(ldap_subdir)
sysconfdir = @address@hidden(ldap_subdir)

(And --without-subdir works).

>I don't see why sysconfdir should be any different than libexecdir.

Well, there is precedent there with at least one package; I'm trying
to understand what makes sense.

>Again, the GNU coding standards don't say that packages can't
>add their name to sysconfdir.  They do say:
>
>    Do not expect the user to include the subdirectory name in the
>    value of any of the variables listed above.
>
>As far as not being able to easily override that, there is precedent
>in other packages.

Yeah, but ... doesn't that seem lousy to you?  This all stems from the
complaint by Steve Winikoff about the extra /nmh being added; It sure
seems to me that if you explicitly specify a directory to configure,
that's what should be used.  (Especially since that's how it was always
done before).  That to me is a completely seperate issue from how OS
packages should be handled; I have no issues there with how things are
done.  We had a user who had to edit the Makefile to get things where
they wanted to be installed, and that just seems like it sucks to me.
If the argument is about DEFAULTS, I wouldn't care so much, but this
sure feels like a regression to me.

But ... what about a compromise?  Like I suggested before, we could
define a precious variable (call it "nmhsysconfdir") and by default
make it be "${sysconfdir}/nmh".  But if you really want to override
it, you could do that on the configure command line.  That seems
easily doable within the confines of Autoconf.  Or something like
what openldap does.

Ralph writes:

> Mind you, it also says /etc is for read-only data particular to a
> machine, e.g. it would be edited.  scan.time should be in
> /usr/share/nmh?  But that's not a 1.7.1 thing.

So, I was curious about that.  WAY back in the MH-6.8 days, both
configuration files AND backend executables were installed in $(ETCDIR),
which defaulted to ... /usr/local/lib/mh.  According to the git history,
as far back as things go $(ETCDIR) was mapped to $(sysconfdir).  I
believe Lyndon pointed out that this sucked that we had executables in
there, and broke things out into $(libexecdir) and $(sysconfdir) (I
don't think that change was controversial, right?), but we never sat
down and talked about $(sysconfdir) being the right choice.  I suppose
there is an argument for those things going in $(datadir), but mts.conf
feels like it might be better in $(sysconfdir).  I am not sure of the
right answer here at all.

--Ken