bug-inetutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-inetutils] Re: DNS SRV support (patch)


From: Simon Josefsson
Subject: [bug-inetutils] Re: DNS SRV support (patch)
Date: Mon, 13 Dec 2004 21:38:19 +0100
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)

"Alfred M. Szmidt" <address@hidden> writes:

>    You could run 'gnulib-tool --import' and import every module, and
>    then modify the generated Makefile to install the library and
>    header files, but other than that, I don't think what you are
>    asking for is possible.
>
> Why not?  One could just add a configure script to gnulib and just
> compile the things that are not in glibc into this library, and then
> install it as libmisc.so or something.

Sure.  I meant that this is not implemented today.

>    I wouldn't agree that a shared library would make things much
>    easier.  It may make some things simpler, but not all things.  For
>    me, the benefits of having more shared stuff in gnulib rather than
>    in a shared library in many cases outweigh the disadvantages.
>
> I don't see the difference, you have to install gnulib in some for to
> have it usable, be it by copying all the needed modules, or by
> installing a shared library.  What benefits are you talking about for
> example?

If the maintainer is the one who copy gnulib into her project, the end
user is relieved of having to install another shared library.

I want my projects to build without any external dependencies on
compliant C89 and/or POSIX platforms, which I can achieve via gnulib.

>    IMHO, InetUtils should have as few external dependencies as
>    possible, to be small and easily ported, which I think would argue
>    for 3).
>
> I strongly disagree with the "to be small and easily ported" part,
> this is not the goal of a GNU project.  The goal is to be as usable
> and featurefull as possible, and to run on the GNU system.  Now if it
> runs on non-GNU and GNU variants, then this is also good, but it isn't
> a primary goal.

I agree.  I believe InetUtils can be both small and easily ported AND
usable and as featurefull as possible.  These aren't necessary
orthogonal goals.  It is just a small matter of good design.

In this case, InetUtils would not lose any usability or functionality
by choosing SRV via gnulib.  On the other hand, without knowing
anything about RULI, I think it is possible that InetUtils may lose
the small and standalone part if InetUtils depend on RULI.

Thanks,
Simon





reply via email to

[Prev in Thread] Current Thread [Next in Thread]