Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Patches: improve innconf.h, remove obsolete docs
(Russ Allbery)
2. Re: Fwd: [[email protected]: [Bug 913539] inn : Conflicts
with libxradius] (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Sun, 24 Feb 2013 10:29:27 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Patches: improve innconf.h, remove obsolete docs
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Richard Kettlewell <[email protected]> writes:
> Taking the same thought a bit further: these headers are pretty free in
> their use of namespace. For instance, xmalloc is very likely to clash
> with a symbol of similar meaning (but not necessarily an identical one)
> in any nontrivial program. Would a patch to improve this be likely to
> be accepted?
Stuff like xmalloc really shouldn't be publicly exposed from libinn at
all. I'd rather see that change than to play games with namespace. To
see the structure that what started as INN's portability layer turned
into, see rra-c-util at:
http://www.eyrie.org/~eagle/software/rra-c-util/
or one of my other projects. This is something that I've kind of wanted
to convert INN to, but haven't had the time. :/
Basically, the bits of libinn that aren't actually useful for clients (and
hence don't have a proper namespace) should move to a libportable or
libutil, which are only used internally by INN and not externally. That
would include all the memory allocation routines and quite a lot of other
stuff. I'm not sure there's really much of libinn that's actually useful
to expose as a shared library other than the nntp routines and innconf,
and maybe confparse, all of which already have proper namespaces. Maybe
inndcomm.h (although it could use some renaming and cleanup first). And
the paths.h header, but there's no actual code behind it.
> What I have in mind is:
> (1) All publicly visible symbols renamed to start inn_
> (or INN_ for things already all upper-case).
This will make it basically impossible to ever merge the current utility
functions with newer versions of the same code from rra-c-util, which
would be unfortunate. That stuff is really intended as a general C
infrastructure layer, which should be split out and used only by the
internal INN code but keep generic names.
> (5) Build the INN libraries as a shared library (or as a collection of
> shared libraries). I can see that this might be more controversial,
> as it would more caution about interface changes than INN has
> presumably required in the past.
Note that this is already done now by default. libinnstorage and
libinnhist aren't in too bad of shape. It's really only libinn that has
lots of interface problems.
--
Russ Allbery ([email protected]) <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.
------------------------------
Message: 2
Date: Sun, 24 Feb 2013 22:33:17 +0100
From: Julien ?LIE <[email protected]>
To: Jochen Schmitt <[email protected]>,
"[email protected]" <[email protected]>
Cc: [email protected]
Subject: Re: Fwd: [[email protected]: [Bug 913539] inn : Conflicts
with libxradius]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hi Jochen,
> as a co-maintainer of the inn package in Fedora, I have got the following
> message from out bug reporting system.
>
> => mod_auth_xradius-0.4.6-17.fc19.src.rpm
> => libxradius-0.4.6-17.fc19.i686 in fedora-development-i386
> File conflict with: inn-2.5.3-8.fc19.i686
> /usr/share/man/man5/radius.conf.5.gz
>
> It's seems, that it's not a good idea to use 'radius' or
> 'radius.conf' as a file names, because there is another package
> which will use this file names.
>
> So I would to like for a hint how we can fix this issue.
According to
https://fedoraproject.org/wiki/Packaging:Conflicts#Man_Page_Name_Conflicts
two usual solutions are suggested:
* Rename the man pages to slightly alter the suffix of the man page (e.g
man1/check.1.gz and man1/check.1foo.gz)
* Rename the man pages to include a prefix of the providing package (e.g.
foo-check.1.gz and bar-check.1.gz)
Couldn't it be possible to rename the radius.conf(5) man page shipped with INN
to inn-radius.conf.5.gz?
Same thing for inn-radius.8.gz?
Perhaps other man pages can also cause problems like history(5), inews(1),
ident(8), domain(8), expire(8)... ?
--
Julien ?LIE
? Tout est dans tout, et r?ciproquement. ? (Pierre Dac)
------------------------------
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
End of inn-workers Digest, Vol 48, Issue 3
******************************************
