Patch: include/paths.h --> include/inn/paths.h in inn-CURRENT

Adam J. Richter adam at
Tue Nov 21 05:56:10 UTC 2006

On Mon, 20 Nov 2006 18:40:28 -0800, Russ Allbery wrote:

>INN does not currently even remotely support the FHS.  There are many,
>many difficulties with installing INN into the correct FHS paths, [...]

	This is a false dependence.  Moving paths.h from
$prefix/include to $prefix/include/inn does not require full FHS
conformance (and, by the way, I currently don't even have an opinion
on full strict FHS conformance).

>[...] 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:

	Moving paths.h now does not force you to abandon any of the
changes you listed as far as I can tell.

	I have, however, taken a look at your proposed other changes
and will comment on them.

> * 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.

	1. The files could move into the inn subdirectory first even if the
other changes are done later.

	2. I am not certain what you mean by "real header guards."
Do you mean "#ifndef INN_INNDCOM_H...#define INCLUDED_INN_H...#endif"?

	3. I am not certain what you mean by "real namespace management."

	4. From extracting the symbols from include/ and
grepping for them in the include/ header files, it looks like you need
to retain config.h in include/inn/ because the information is needed
to define system-dependent functions differently based on
in this as far as I can tell; just move config.h to inn/config.h.  In
the future, you could potentially split config.h in private and public
parts, but such a change is not a dependency on these changes.

> * Existing uses of nntp.h should be changed to use inn/nntp.h, which
>   mostly means changing the name of constants.

	After that, you want to delete nntp.h, right?  At some time in the
future, it would probably be useful to split inn/nntp.h into
inn/nntp_protocol.h and inn/nntp_funcs.h, but, again, this is not a

	Also, this would be a much more readable patch if separately

> * dbz.h is not a public header file and shouldn't be installed; it
>   will eventually move into the history directory.

	I haven't look enough at the inn internals to understand what
you would do with expire/makedbz.c and lib/dbz.c (the only files
outside of the history directory that #include dbz.h), but, so far, it
seems to me like this task does not depend much on the other changes
you've described and the other changes would not depend at all on it.

> * 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.

	A little shell scripting indicates that the only conflict that
might be created by globally replacing all of the _PATH symbols to
INN_PATH is INN_PATH_COMPRESS in m4/compress.m4, which looks like it is
not used and therefore can be deleted.

> * 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.

	Looking at include/Makefile, it looks like just a matter of
deleting the stuff that refers to $(PUBLIC).

>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.

	I guess additional FHS changes are laudable, but, again, it's
not a dependency, and would probably actually better to process

>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 noticeable
>further progress on my plan for solving this problem by the beginning of
>2007, I will seriously reconsider your patch and approach.

	I'm not asking you to work harder.  In fact, I think the
maintainer bottleneck is one of the biggest problems in free software
development today.  Instead, I'm asking you to work more incrementally
to make it easier for others to do more of the work for you.

	For instance, in the case of these changes to the include/
hierarchy, you seem to want to have one big flag day for users of the
inn libraries so that they will only have to change things once.
However, with incremental updates, it's more likely that when
compilation of those libraries break, it will be easier to identify
which change caused it and fix that change incrementally.  So, on the
balance inn library users would probably be no worse off, since the
changes that I'm talking about are not ones that would be reversed by
any of your proposals.

	Most of the changes that you are talking about are pretty
straightforward if processed separately.  It's only when if one
insists on the unnecessary requirement of making the changes
simultaneous that they create a headache.

	So, I have a counterproposal.  Integrate all of the changes
that I've submitted so far except in cases where you see an actual
bug, I'll take a whack at some of the easier problems on that TODO
list this week and submit them incrementally, you'll incrementally
integrate those that look OK, and perhaps consider a more "early and
often" release policy.  I think you'll find that that will also
facilitate more contribution from others and will result in more
progress the this week than the alternative is likely to produce by
the end of year.

Adam Richter

More information about the inn-workers mailing list