On Mon, Mar 17, 2003 at 08:18:23PM +0100, Martin Sjögren wrote:
> mån 2003-03-17 klockan 19.18 skrev Denis Barbier:
> > > I would think it obvious that they would be significant inside the
> > > strings I want to substitute in.
> >
> > But this is not always possible, consider the shell confmodule for instance,
> > spaces between arguments are gobbled by the shell.
>
> Are they? db_subst foo/bar NAME "..." Will that be gobbled?
With current implementation, yes.
> > > > But is there a need for -dev at all? debconfclient.[ch] should go into
> > > > debconf, these files define a C interface similar to current Perl, Python
> > > > or shell ones. Other .h files are useless, aren't they?
> > >
> > > debconf or cdebconf?
> >
> > debconf.
> > The debconfclient.[ch] files are similar to /usr/share/debconf/confmodule,
> > /usr/share/perl5/Debconf/Client/ConfModule.pm and
> > /usr/lib/python2.2/site-packages/debconf.py
> > Perl, python and shell confmodule's are shipped by debconf, so why not C?
>
> But debconfclient.h isn't necessary for *running* a C program that uses
> the C interface. Policy dictates a split in runtime package and devel
> package, doesn't it? Do we really want to stick a shared library in the
> debconf package? What about when the soname changes?
>From the debconf specs:
Configuration frontends
Of course applications can use the database and meta-database
directly. But there should be a simple system to interact
with the user that is simple and modular enough to be used
with systems ranging from shell-scripts to Fortran programs.
To do this we define a general frontend that can be driven
using the simplest and most common form of communication:
stdin and stdout.
My point is that there are perl, python and shell bindings, but
C bindings are provided by cdebconf together with lots of
cdebconf (useless) specific stuff.
Denis
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
