Re: building own package
(You may - or may not - have more luck on debian-mentors@l.d.o for
that kind of questions.)
On Wed, Aug 03, 2005 at 11:21:35AM +0200, Tomas Davidek wrote:
> * I store all the scripts in a tarball,
Do you mean the .orig.tar.gz or do you mean a tarball in the unpacked
Debian sources (the result of dpkg-source -x foo.dsc)?
> -------------
> clean:
> rm -fr debian/ucjf-security
>
> install:
> cd $(DESTDIR) ; \
> tar -xvzf ../../../ucjf-security_1.0.1.orig.tar.gz
> --------------
I'd suggest:
install:
tar -xzf foo.tar.gz --directory=debian/ucjf-security
Unless you have a specific reason not to do so (non-Debian machines,
for example) I'd also you could put these commands in the debian/rules
directly.
> It works, however I would expect that the path to a tarball can be
> specified in a better way (is there any variable containing the top
> directory name ?).
Yes, PWD. debian/rules is guaranteed to be called from the package
top-level.
> Also, the version should not be hardcoded there, I guess.
If you have a tarball in the unpacked Debian sources, there is no
reason to have its name contain the version. Or if you really want to
do that, you'll have only one and thus you can use a shell pattern to
catch it, like "foo-*.tar.gz".
If you are using the .orig.tar.gz directly, you have misunderstood the
structure of a Debian source package: The .orig.tar.gz is unpacked,
the tree is patched with the .diff.gz and then one builds / installs
entirely from there.
You may actually want to do a "Debian native" package that has only a
.tar.gz and no .diff.gz.
> * since the pakcage contains only few shell scripts, it should be
> architecture-independent. Therefore, I specified "Architecture: any"
> in the "control" file
You want "Architecture: all". "any" means it is
architecture-dependent, but should be compiled for all architectures.
> * the script don't have any config file, therefore I didn't
> introduce the "conffiles" in the debian directory. However, the
> resulting package contains in its conffiles the first file of the
> tarball. Is there a good reason for that ?
I couldn't say how this happened without seeing your package. Maybe
the "first file" is installed in /etc/? It is labelled a conffiles by
default (with debhelper) then.
(Don't show me your package if you don't want me to steal ideas / code
from it for my own use or other Free Software projects.)
> * the man pages installation works pretty well, the only problem is that
> the mandb is not updated after the package installation. It means user
> can display the new manpage, but "man -k" does not find it. One would
> need to run mandb automatically - should this be done via postinst
> (postrm) scripts or is there a simpler way to do so ?
It is done automatically every day on every machine by cron. AFAIK,
packages are not supposed to trigger mandb immediately, just to rely
on the daily run of it.
--
Lionel
Reply to: