Re: building own package
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/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 - 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
building own package
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 : [EMAIL PROTECTED], [EMAIL PROTECTED] #!/usr/bin/make -f # -*- makefile -*- # Sample debian/rules that uses debhelper. # This file was originally written by Joey Hess and Craig Small. # As a special exception, when this file is copied by dh-make into a # dh-make output file, you may use that output file without restriction. # This special exception was added by Craig Small in version 0.37 of dh-make. # Uncomment this to turn on verbose mode. export DH_VERBOSE=1 CFLAGS = -Wall -g ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) CFLAGS += -O0 else CFLAGS += -O2 endif configure: configure-stamp configure-stamp: dh_testdir # Add here commands to configure the package. touch configure-stamp build: build-stamp build-stamp: configure-stamp dh_testdir # Add here commands to compile the package. $(MAKE) #docbook-to-man debian/ucjf-security.sgml ucjf-security.1 touch build-stamp clean: dh_testdir dh_testroot rm -f build-stamp configure-stamp # Add here commands to clean up after the build process. -$(MAKE) clean dh_clean install: build dh_testdir dh_testroot dh_clean -k dh_installdirs # Add here commands to install the package into debian/ucjf-security. $(MAKE) install DESTDIR=$(CURDIR)/debian/ucjf-security # Build architecture-independent files here. Everything here, since we have # just set of scripts: binary-indep: build install dh_testdir dh_testroot dh_installchangelogs dh_installdocs README TODO dh_installexamples # dh_install # dh_installmenu # dh_installdebconf # dh_installlogrotate # dh_installemacsen # dh_installpam # dh_installmime # dh_installinit # dh_installcron # dh_installinfo dh_installman ucjf-security.8 dh_link dh_strip dh_compress dh_fixperms # dh_perl # dh_python # dh_makeshlibs dh_installdeb dh_shlibdeps dh_gencontrol dh_md5sums dh_builddeb # Build architecture-dependent files here. binary-arch: build install # We have nothing to do by default. binary: binary-indep binary-arch .PHONY: build clean binary-indep binary-arch binary install configure
Re: building own package
(You may - or may not - have more luck on [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: building own package
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 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: building own package
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:
* I store all the scripts in a tarball,
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 : [EMAIL PROTECTED],
[EMAIL PROTECTED]
dpkg-buildpackage: source package is ucjf-security
dpkg-buildpackage: source version is 1.0.2-1
dpkg-buildpackage: source maintainer is Tomas Davidek [EMAIL PROTECTED]
dpkg-buildpackage: host architecture is i386
fakeroot debian/rules clean
dh_testdir
dh_testroot
rm -f build-stamp configure-stamp
# Add here commands to clean up after the build process.
#-/usr/bin/make clean
dh_clean
rm -f debian/ucjf-security.substvars
rm -f debian/ucjf-security.*.debhelper
rm -rf debian/ucjf-security
rm -f debian/files
find . -type f -a \( -name \#\*\# -o -name .\*\~ -o -name \*\~ -o -name
DEADJOE -o -name \*.orig -o -name \*.rej -o -name \*.bak -o -name .\*.orig -o
-name .\*.rej -o -name .SUMS -o -name TAGS -o -name core -o \( -path
\*/.deps/\* -a -name \*.P \) \) -exec rm -f {} \;
rm -rf autom4te.cache
dpkg-source -b ucjf-security-1.0.2
dpkg-source: building ucjf-security using existing
ucjf-security_1.0.2.orig.tar.gz
dpkg-source: building ucjf-security in ucjf-security_1.0.2-1.diff.gz
dpkg-source: warning: ignoring deletion of directory sbin
dpkg-source: warning: ignoring deletion of file sbin/hledej_skodice
dpkg-source: warning: ignoring deletion of file sbin/ipt-skodici
dpkg-source: building ucjf-security in ucjf-security_1.0.2-1.dsc
debian/rules build
dh_testdir
# Add here commands to configure the package.
touch configure-stamp
dh_testdir
# Add here commands to compile the package.
#/usr/bin/make
#docbook-to-man debian/ucjf-security.sgml ucjf-security.1
touch build-stamp
fakeroot debian/rules binary
dh_testdir
dh_testroot
dh_clean -k
rm -f debian/ucjf-security.substvars
rm -f debian/ucjf-security.*.debhelper
rm -rf debian/ucjf-security
find . -type f -a \( -name \#\*\# -o -name .\*\~ -o -name \*\~ -o -name
DEADJOE -o -name \*.orig -o -name \*.rej -o -name \*.bak -o -name .\*.orig -o
-name .\*.rej -o -name .SUMS -o -name TAGS -o -name core -o \( -path
\*/.deps/\* -a -name \*.P \) \) -exec rm -f {} \;
rm -rf autom4te.cache
dh_installdirs
install -d debian/ucjf-security
install -d debian/ucjf-security/usr/sbin
# 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
#!/usr/bin/make -f
# -*- makefile -*-
# Sample debian/rules that uses debhelper.
# This file was originally written by Joey Hess and Craig Small.
# As a special exception, when this file is copied by dh-make into a
# dh-make output file, you may use that output file without restriction.
# This special exception was added by Craig Small in version 0.37 of dh-make.
# Uncomment this to turn on verbose mode.
export DH_VERBOSE=1
CFLAGS = -Wall -g
ifneq
Re: building own package
On Wed, Aug 03, 2005 at 04:42:33PM +0200, Tomas Davidek wrote: Lionel Elie Mamane wrote: On Wed, Aug 03, 2005 at 11:21:35AM +0200, Tomas Davidek wrote: * I store all the scripts in a tarball, 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. 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
