[ENBD] Bring enbd back in Debian?

[Bas van Schaik]

Peter T. Breuer wrote:

>"Also sprach Bas van Schaik:"
>  
>
>>Hmmm... You've got a point here! Maybe it's a better idea not to split
>>the init-script, and put the common init script in a common-package. So,
>>    
>>
>
>I haven't split the script. It starts whatever it can as specified
>in the server and/or client configs, provided that there is also
>the corresponding daemon present.
>  
>
Excellent!

>>the /etc/init.d/enbd script will parse both client and server
>>configuration files and will start/stop the clients and servers.
>>However, if the scripts detects a server configuration file on a system
>>without the enbd-server binaries, it should exit with an error.
>>    
>>
>
>Well, I don't think that's right! Debian always is happy leaving config
>files around after removing the package. There's no need to error in 
>that case (say the server is not present, but its config file is), since
>the other daemon (the client, in this case) might still be there and one
>wants to maybe start it.  One should just make a best effort to start
>what one can.  That's what happens at present (2.4.33, as uploaded a few
>minutes ago).
>  
>
You're completely right. I've just downloaded 2.4.33-pre and I'm
currently checking it out.

>>with the init-script. However, I prefer the splitted setup of the
>>configuration files and manpages, but that's just my humble opinion ;).
>>    
>>
>
>There's nothing wrong with splitting - it just apparently implies that
>the init script should go in a (third) enbd-common or enbd-base package,
>since making two scripts, one for each of the split packages, would be
>duplication of significant functionality.
>
>I could split off a common library too, if that helps.
>  
>
It's of course not necessary, but if it prevents code duplication: don't
hesitate, just do it! Since there'll be an common-package anyway, you
can refactor any duplicate code into one library.

>At the moment I have made it easy for you to change the sitings of
>things via this stuff passed to the compiler ...
>
>  gcc -DCONFDIR="\"/etc\"" -DPIDDIR="\"/var/run\"" -DSTATEDIR="\"/var/state/enbd\""  ...
>
>That's produced in the Makefile (which comes from Makefile.in) and that
>needs patching. It produces those values based on sysconfdir,
>localstatedir from ./configure, but you probably want to edit the
>Makefile.
>  
>
I'm not I understand this fully. I think it's the easiest way for me to
configure such things in the "main" Makefile, which is extracted in the
package root. To be sure we're talking about the same file, here's the
directory structure after extracting:

> enbd-2.4.33/debian/...
> enbd-2.4.33/nbd/...
> enbd-2.4.33/nbd/Makefile(.in)     <-- NOT this one
> enbd-2.4.33/Makefile     <-- this one!

Until now, this Makefile was the only file which needed editing (not
much anyway), so if it's possible to put those CONFDIR, PIDDIR and
STATEDIR-parameters in there (also), it would save me some patching!
By the way, I think the "debian"-directory in the archive is not really
needed for anything anymore. It would be easier if this directory was
removed, because the Debian buildscripts are complaining about a
duplicate "debian" directory (my own build config, and the pre-existing
one). I've extracted all the needed information from it (and it'll stay
old archives anyway), so I think there's no reason to keep it there.

I'm currently testing enbd from packages on real hardware, and it seems
to work great! Today I'll try to package all stuff from /etc in the
common-package with some configuration examples. Do you want me to split
the manpages for the client and server? It's not that much work and I
think it'll save you some time. Just let me know.

-- Bas