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

Russ Allbery rra at stanford.edu
Tue Nov 21 06:18:27 UTC 2006


Adam J Richter <adam at yggdrasil.com> writes:
> 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).

Right, no, I understand.  I was commenting on the general FHS discussion
as well.

BTW, thank you for your patience and willingness to continue to discuss
this.  I'm a little prickly on the subject, which I realize, and I do
appreciate you being willing to talk through this with me.

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

Yeah, I'm starting to see your point.

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

Agreed.  I should just do that and be done with it.  There's other stuff
in the inn subdirectory that needs cleanups anyway.

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

Yes.

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

INN's libraries export far too many functions that don't have any clear
namespace (preferrably inn_*, but things like vector_* and buffer_* will
probably stay that way).  But this is more a long-term goal and doesn't
need to be tied to any of this.

> 	4. From extracting the symbols from include/config.h.in 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
> INN_HAVE_C99_VAMACROS and HAVE_UNIX_DOMAIN_SOCKETS.  There is no sin
> 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.

This is already taken care of in the Subversion trunk.  inn/defines.h is
built dynamically at build time from config.h and renames the symbols to
not conflict with other packages.  If it's really important to fix this
for STABLE (something that's not horribly appealing to me, but I guess I
could be talked into it), the same technique can be used.

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

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

Yeah, I've been pondering that.

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

Agreed.

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

lib/dbz.c also needs to move inside the history code.  makedbz is an
unresolved problem; I'm not really sure the best way to handle it.
Anyway, agreed, this stuff can wait.

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

That's just the name of an Autoconf macro; there's no conflict there.
Yeah, I expect this is easy.

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

Right.  Most of the footwork has already been done.

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

Okay, deal.  I'll try to integrate the path changes tonight or tomorrow,
and we'll see how it goes.

I'm going to commit them just to the trunk for right now; how important do
you feel it is to push them to the 2.4 branch?  This is the sort of change
that normally I haven't been considering appropriate for the 2.4 branch,
and I wonder if I shouldn't just finish up a few things on trunk and
release 2.5 given that a lot of code has already changed there and it's
been quite a while since the last major release.

I got myself stuck behind a goal of getting particular features done by
particular releases and therefore haven't been releasing INN very often,
which was a mistake.  (I do a much better job at release early, release
often with the other packages I maintain.)

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>


More information about the inn-workers mailing list