Hello,
I am trying to build my own package (containing only few shell
scripts) to make easier the system maintainance specific to our
department. I followed the instruction in the Debian New Maintainer's
Guide, but I probably misunderstood something, since I have the
following problems:

* I store all the scripts in a tarball, so all I have to do is to unpack
them in the respective directory during the "make install" stage (i.e.
no compilation is needed). I succeeded to do so by introducing  the
following Makefile:
-------------
clean:
rm -fr debian/ucjf-security

install:
cd $(DESTDIR) ; \
tar -xvzf ../../../ucjf-security_1.0.1.orig.tar.gz
--------------
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 ?). Also, the version should not be hardcoded there, I
guess. Is there a way to tell the Makefile to use the latest
version/same version as is the name of the working directory ?

* since the pakcage contains only few shell scripts, it should be
architecture-independent. Therefore, I specified "Architecture: any" in
the "control" file and also moved all the action in the "rules" file
into the binary-indep section (see attachment).... However, the
resulting package still contains in its control file the item
"Architecture: i386" (which is where the package is produced, but ....).

* 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 ? How do I get rid off this feature ?

* 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 ?

Thanks a lot for any hint,

best regards
Tomas

E-mail : davidek@ipnp.troja.mff.cuni.cz,
Tomas.Davidek@cern.ch

[ Post a follow-up to this message ]

(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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

On Wed, Aug 03, 2005 at 11:21:35AM +0200, Tomas Davidek wrote:
> * since the pakcage contains only few shell scripts, it should be
> architecture-independent. Therefore, I specified "Architecture: any" in
> the "control" file and also moved all the action in the "rules" file
> into the binary-indep section (see attachment).... However, the
> resulting package still contains in its control file the item
> "Architecture: i386" (which is where the package is produced, but ....).

You want "Architecture: all", not "Architecture: any". See the policy
manual.

> * 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 ?

Please just leave this alone; no other package does anything like this,
and it would be enormously inefficient for every package that shipped a
man page to run mandb in its postinst. The eventual right answer, I
think, is for dpkg to support triggers so that packages that ship man
pages can cause mandb to be invoked at the end of the dpkg run - and
this is on the dpkg development wishlist - but in the meantime just let
the daily cron job take care of it.

Cheers,

--
Colin Watson                                       [cjwatson@debian.org]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

Hello again,
thanks to all who replied to my previous mail. Using your advice I
solved/correct all the problems/bugs, but still there is one thing I
don't understand:

Lionel Elie Mamane wrote:

>On Wed, Aug 03, 2005 at 11:21:35AM +0200, Tomas Davidek wrote:
>
> 
>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.
>
>
Yes, this is exactly the problem - the *.orig.tar.gz should be unpacked,
but apparently it is not. When I have in my makefile:
.....
install:
cp -a usr $(DESTDIR)/usr
.....
it fails with the error message:
--------------
# Add here commands to install the package into debian/ucjf-security.
/usr/bin/make install
DESTDIR=/home/davidek/debian/ucjf-security-1.0.2/debian/ucjf-security
make[1]: Entering directory `/home/davidek/debian/ucjf-security-1.0.2'
cp -a usr /home/davidek/debian/ucjf-security-1.0.2/debian/ucjf-security/usr
cp: cannot stat `usr': No such file or directory
make[1]: *** [install] Error 1
make[1]: Leaving directory `/home/davidek/debian/ucjf-security-1.0.2'
make: *** [install] Error 2
---------
Someone of you mentioned that it should be debian/rules script that
unpacks the .orig.tar.gz. I tried to issue the commands one-by-one, but
none of them unpacked the orig tarball. BTW, should it be unpacked into
/home/davidek/debian/ucjf-security-1.0.2 (see above) or somewhere else ?

I probably miss something in the debian/rules (attached), the full
output of dpkg-buildpackage -rfakeroot is also attached.

Thanks a lot for help,

best regards

Tomas

E-mail : davidek@ipnp.troja.mff.cuni.cz,
Tomas.Davidek@cern.ch

[ Post a follow-up to this message ]

On Wed, Aug 03, 2005 at 04:42:33PM +0200, Tomas Davidek wrote:
> Lionel Elie Mamane wrote: 
[vbcol=seagreen] 
[vbcol=seagreen] 
[vbcol=seagreen] 
[vbcol=seagreen]
> Yes, this is exactly the problem - the *.orig.tar.gz should be unpacked,
> but apparently it is not.

OK. Please describe the files you think make up the source
package. You should have (for some value of foo):

- a foo-1.dsc file
- a foo-1.diff.gz file
- an foo.orig.tar.gz file

To unpack this source package, you issue the command:

dpkg-source -x foo-1.dsc

This unpacks the whole thing into ./foo/: The .orig.tar.gz and the
.diff.gz applied to it.

In order to construct the dsc/diff, you:

1) Make the .orig.tar.gz
2) unpack it manually into ./foo/
3) Add the directory ./foo/debian/ and its contents
4) Run "debuild -S"

--
Lionel


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

On Wednesday 03 August 2005 08:12 PM, Tomas Davidek wrote:

> Yes, this is exactly the problem - the *.orig.tar.gz should be unpacked,
> but apparently it is not. When I have in my makefile:
> .....
> install:
>          cp -a usr $(DESTDIR)/usr
> .....
> it fails with the error message:
> --------------
> # Add here commands to install the package into debian/ucjf-security.
> /usr/bin/make install
> DESTDIR=/home/davidek/debian/ucjf-security-1.0.2/debian/ucjf-security
> make[1]: Entering directory `/home/davidek/debian/ucjf-security-1.0.2'
> cp -a usr /home/davidek/debian/ucjf-security-1.0.2/debian/ucjf-security/us
r
> cp: cannot stat `usr': No such file or directory
> make[1]: *** [install] Error 1
> make[1]: Leaving directory `/home/davidek/debian/ucjf-security-1.0.2'
> make: *** [install] Error 2
> ---------

Its clearly mentioned in the New Maintainers' guide that you have to
create the directory in your Makefile as 'usr' directory will already
exsit on your system.Since you are installing it in your them directory
i.e debian/ucjf-security.Just add any one of these lines:

install -d $(DESTDIR)/usr
or
mkdir $(DESTDIR)/usr

it will work fine.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]