mån 2003-03-17 klockan 21.20 skrev Denis Barbier: > > Are they? db_subst foo/bar NAME "..." Will that be gobbled? > > With current implementation, yes. Then I think that should be changed too! > > 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. Yes, fine, but I think it's a bad idea to change debconf from arch all to arch any just to include the C interface. As I said, I see no problem splitting libdebconf in one backend and one frontend part, and I think it's quite all right to have C backend support installed along with debconf, but why can't debconf just depend on the appropriate package(s)? I don't care whether the debconfclient.[ch] files are in the debconf or cdebconf *source* package. Joey, Randolph, any comments? /Martin -- Martin Sjögren sjogren@debian.org -- marvin@dum.chalmers.se GPG key: http://www.mdstud.chalmers.se/~md9ms/gpg.html let hello = "hello" : hello in putStr (unlines hello)
Attachment:
signature.asc
Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel