Re: debstd-like tool for those who don't want to use debmake
> I think if we'd use automake (or a similar tool) the effect would be the
> opposite.
why ?
(btw : we can't use automake. but we can create something that works the
same way).
>
> (If you think I missed automake purposes totally--which is likely to be
> the case--please show me how a new debian/rules file would look like.)
thats not easy.... i don't know exaclty. mabe like this : debian/rules.ar
build:
(export CPPFLAGS="-I`cd ../../kdeusr/usr/include/kde;pwd`" \
LIBS="-L`cd ../../kdeusr/usr/lib;pwd`" \
SETUIDFLAG="-m 2755 -g shadow"; \
./configure --prefix=/usr --with-shadow)
make CFLAGS="-O2 -g -Wall"
binary-arch:
MKDIR usr/doc/kdebase
INSTALL debian/xdmconfig usr/sbin
WATCH ftp.kde.org /pub/kde/unstable/distribution/tgz/current \
kdebase-*.tar.gz debian uupdate
@AFTER_INSTALLATION@
cp ../../kdeusr/shlibs.local debian/shlibs.local
KDE_INSTALL_DOCS
KDE_CORRECT_PATHS
KDE_DEPENDS
the debian/rules file would be very long (think of joeyh's debian/rules,
but all commands are in the debian/rules file and not in external
scripts).
expressions like KDE_INSTALL_DOCS will be replaced with rules like :
cp -aP `find -regex ".*/[A-Z]*" -or -name "*README*" \
-or -name ChangeLog -or -name "*lsm" -or -name "SWALLOW*" \
-or -name "TODO*"|egrep -v "(debian|INSTALL)" ` \
debian/tmp/usr/doc/$(PACKAGE)
and because i used $(PACKAGE) at the beginning of the file will be
PACKAGE=kdelibs (autorules will take care of this).
KDE_CORRECT_PATHS would move all /usr/bin files to /usr/X11R6/bin,
libs to X11R6/libs etc.
KDE_DEPENDS would calculate the dependencies with using
~/debian/kdeusr/shlibs.local as additional definition source. ...
to compare this : my current debian/rules is :
#!/usr/bin/make -f
# Made with the aid of debmake, by Christoph Lameter,
# based on the sample debian/rules file for GNU hello by Ian Jackson.
build:
$(checkdir)
(export CPPFLAGS="-I`cd ../../kdeusr/usr/include/kde;pwd`" \
LIBS="-L`cd ../../kdeusr/usr/lib;pwd`" \
SETUIDFLAG="-m 2755 -g shadow"; \
./configure --prefix=/usr --with-shadow)
make CFLAGS="-O2 -g -Wall"
touch build
clean:
$(checkdir)
-rm -f build
-make distclean
-rm -f `find . -name "*~"`
-rm -rf debian/tmp debian/files* core debian/substvars
binary-indep: checkroot build
$(checkdir)
# There are no architecture-independent files to be uploaded
# generated by this package. If there were any they would be
# made here.
binary-arch: checkroot build
$(checkdir)
-rm -rf debian/tmp
install -d debian/tmp
cd debian/tmp && install -d `cat ../dirs`
make install prefix=`pwd`/debian/tmp/usr
# Must have debmake installed for this to work. Otherwise please copy
# /usr/bin/debstd into the debian directory and change debstd to debian/debstd
cp ../../kdeusr/shlibs.local debian/shlibs.local
cp -aP `find -regex ".*/[A-Z]*" -or -name "*README*" \
-or -name ChangeLog -or -name "*lsm" -or -name "SWALLOW*" \
-or -name "TODO*"|egrep -v "(debian|INSTALL)" ` \
debian/tmp/usr/doc/kdebase
(export LD_LIBRARY_PATH="`cd ../../kdeusr/usr/lib; pwd`"; debstd -m)
dpkg-gencontrol
chown -R root.root debian/tmp
chmod -R go=rX debian/tmp
dpkg --build debian/tmp ..
define checkdir
test -f debian/rules
endef
# Below here is fairly generic really
binary: binary-indep binary-arch
checkroot:
$(checkdir)
test root = "`whoami`"
.PHONY: binary binary-arch binary-indep clean checkroot
you see, the rules.ar is much shorter.
the new rules file will be much longer : it would include nearly the
debstd code, or it would also generate a rules.sh and call this.
anyway, its far more flexible, because you can change and redefine every
command. with joeyh's solution i would have to patch his files, and
include my changes command in debian/. that's why i like an automake
style : it is more flexible.
another example : maybe you decide to split a package.
with debmake (and i didnt read that joeyh will change that) i have to
look at the multi file examples, compare them to my rules file, and add
the missing commands. with an autorule, i only edit the control file,
rerun autorules, and it will give warnings if i forgot to change
something.
for me, it looks like debstd and joeyh's d2 give additional tools, and
i still have to use these tools myself. so i have to say what it should
do. the autorule design would be to do the work. i don't say what it
should, i say how it should do something.
and i want to get rid of some of the files in debian/* : dirs, files,
watch ... calling a macro with a parameter is better IMO, and autorules
will still be able to detect existing dir,files,watch files, and handle
them or convert them to a new rules.ar file.
and i want to get rid of saying everything twice :
for example with current debmake and multi binary package rules, i have
to say dpkg-gencontrol -pPRIMARYPACKAGE. but the primary package is the
first in the control file. no need to say that twice.
good tools are nice. after you found out, that you need to run a tool,
you can work with it. with an autorules design i get an extra wizard
that tells me what tools i need to run (and in many cases he can do it
without asking me and me adding something to the config file).
and uh, i forgot : autorules could work on top of debstd / joeyh's tool
(but it would be easier if it did everything directly).
andreas
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: