Patch: include/paths.h --> include/inn/paths.h in inn-CURRENT
rra at stanford.edu
Tue Nov 21 02:40:28 UTC 2006
INN does not currently even remotely support the FHS. There are many,
many difficulties with installing INN into the correct FHS paths, some of
which can be worked around and some of which are obnoxious. In order to
correctly support FHS paths, again, real design work is needed and
significant changes to how INN internally handles paths are required.
(You don't have to convince me that supporting the FHS is the right way to
go; you would be entirely preaching to the choir. INN's path handling is
old and crufty, and I want to engineer a solution that doesn't change the
defaults for existing INN users.)
I realize that you want a fast solution now to a problem that you're
encountering and that you're frustrated by my unwillingness to commit a
partial solution. I'm sorry; I'm not doing it to annoy you. I recognize
the problem that you're trying to solve and believe it to be even more
severe than you've yet encountered, and I have a plan for how I want to
deal with it that I'm not ready to abandon for shorter-term fixes that
move a bunch of things around and touch a lot of files without addressing
the deeper underlying problems. Specifically, what needs to happen is:
* The header files inndcomm.h, libinn.h, ov.h, and storage.h need to
move into the inn subdirectory and acquire real header guards, real
namespace management, and in some cases a saner API (although some of
the API changes can wait). Any dependencies on config.h must also be
removed in the process.
* Existing uses of nntp.h should be changed to use inn/nntp.h, which
mostly means changing the name of constants.
* dbz.h is not a public header file and shouldn't be installed; it
will eventually move into the history directory.
* paths.h should move into the inn directory, all the constants should
be modified to not violate C namespace rules and start with INN_*,
and all the users should be updated accordingly.
* After that's done, none of the headers outside of the inn directory
should be installed at all; they are used only when building INN and
should not be used by clients of INN's libraries.
To support the FHS properly, INN also needs to split bin, sbin, and helper
programs that belong in lib into three separately-controlled paths. Then,
there should probably be an --enable-fhs option that does all the
appropriate things to all of the other path settings so that the user
doesn't have to set them all themselves.
Hoping to do this may be short-sighted or far too optimistic on my part, I
realize, but right now you're probably not going to succeed in changing my
mind. I will make a deal with you, though: If I've not made noticable
further progress on my plan for solving this problem by the beginning of
2007, I will seriously reconsider your patch and approach.
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
More information about the inn-workers