Re: Re: [Refdb-users] ANN: RefDB RPM packages pulled, packagers wanted

Markus Hoenicka wrote:

>David Nebauer writes:
> > Two things I'd like the Debian install process to do that don't happen 
> > in the current standard install are:
> > 
> > 1.  Install the refdb daemon. 
>
>I'm not sure whether installing a daemon should be part of the regular
>installation process of a tarball. Daemon installation is all too
>OS-dependent. On the BSD's you'd have to use /usr/local/etc/rc.d/ and
>rename refdb to refdb.sh, on Windows you have to use a special tool
>called cygrunsrv to install refdbd as a service (refdb is not involved
>at all), and hell knows how this might work on OSX. If you install
>RefDB with the current build process, it is ready to run from the
>command line. Everything else should be handled by the OS-specific
>port or package code. I'm sure the Debian package system provides a
>way to run something like an install script after the
>autotools-controlled installation.
>  
>
Ah, I see how my choice of words misled you.  I did not want you to make 
an upstream change to the install process.  The change I want to make is 
only for the Debian install.  The packaging process involves building 
the application from source and so I would make the changes only to the 
local source tree I am creating the package from.  There are also pre- 
and post-install scripts.  The process of adding the links to the /etc 
tree is handled by the post-install script.  From what I have observed 
of other packages, however, the daemon script is usually copied to the 
/etc/init.d directory by the standard install process.  I presume this 
involves a simple one-line copy command inserted into one of the make 
files.  If you can show me where this command would go I would make the 
alteration to my debian build system which would result in the 
subsequent deb package copying the daemon to /etc/init.d.

> > 2.  Copy a html version of the manual to debian's document system.  What 
> > changes would be required to accomplish this?
> > 
>
>You've found a weak spot that I hoped no one would ever notice. The
>documentation is not integrated into the build process so far. I think
>about moving the documentation over to DocBook XML and use xsltproc to
>transform it. This would not create additional dependencies as we need
>xsltproc and the DocBook stylesheets anyway. In that case, "make
>install" would put the docs into a directory which would be customizable
>with another configure switch.
>  
>
This would certainly accomplish the desired result.  Again, however, I 
was thinking of something simpler and just for the Debian install: I'd 
wget the html manual files from the refdb website and add a copy command 
to the build process that would install them as part of the debian 
package install.

> > Here are some of the components of the Debian install process as I've so 
> > far designed it.  Please feel free to comment on any changes you think 
> > advisable:
> > 
> > Dependencies:
> > docbook-xsl (>= 1.66.1-1), libacl1 (>= 2.2.23-1), libattr1 (>= 
> > 2.4.16-1), libexpat1 (>= 1.95.8-1), libreadline4-dev (>= 4.3-11), 
> > libxml2 (>= 2.6.16-3), libxml2-utils (>=2.6.16-3), libxml-parser-perl 
> > (>= 2.34-4), zlib1g (>= 1), libdbi0-dev (>= 0.7.2-1), sqlite 
> > (>=2.8.16-1), libdbd-sqlite (>=0.7.1-2), sgml-data (>=2.0.2)
> > 
>
>- What do libacl1 and libattr1 do?
>  
>
The Debian New Maintainers' Guide gives a couple of commands that 
analyse a configure file and extract/construct a list of dependencies:

strace -f -o /tmp/log ./configure
for x in `dpkg -S $(grep open /tmp/log|\
                      perl -pe 's!.* open\(\"([^\"]*).*!$1!' |\
                      grep "^/"| sort | uniq|\
                      grep -v "^\(/tmp\|/dev\|/proc\)" ) 2>/dev/null|\
                      cut -f1 -d":"| sort | uniq`; \
        do \
          echo -n "$x (>=" `dpkg -s $x|grep ^Version|cut -f2 -d":"` "), "; \
        done

The two packages you queried were included in the output and I accepted 
the dependencies "on trust:.  The obvious test is to install refdb on a 
debian system lacking these packages and see whether it works.  This is 
not practicable as half the system packages depend on these two, either 
directly or indirectly.  Since most systems will have these two packages 
installed anyway I saw little harm in leaving them in the dependency list.

>- libxml-parser-perl required for?
>  
>
It provides the perl module 'XML::Parser'.  As the import filter perl 
module dependencies are optional I have moved it to the suggested 
package list.

>- I don't see xsltproc and/or libxslt here?
>  
>
Quite simply an error on my part.  Since 'xsltproc' depends on 
'libxslt1.1' only the former is required.

>- isn't libdbi0 required as well to run the drivers?
>  
>
If you look more closely you'll see that libdbi0-dev is listed as a 
dependency.  It depends on libdbi0 and so the latter becomes an indirect 
dependency.

As mentioned above, any pointers on how to adjust the build system to 
copy the daemon and help files would be appreciated.

Regards,
David.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click