Re: Do you use the DBS? Document it!
On Wed, 5 Jun 2002, Marcelo E. Magallon wrote:
> Would you people using the DBS or some customized version of it please
> do two things:
>
> * Settle on a way to unpack and patch the sources
By using the only official way, sys-build.mk.
> * Provide a debian/README.packaging where it says how to do the
> above until you settle on a method?
Lots of people tend to treat patch files as unmodifiable. Lately, however,
I've been tending to add descriptions to the top of each patch file,
explaining where it was gotten(or why it exists). This includes when I import
a patch from some place like sourceforge's patch system(or bug tracker).
A previous version suggested using README.patches, to document each patch.
This became hard to keep uptodate, as it separated the description from the
patch it described.
note: The latest unreleased version of dbs supports patch dependencies(woo!).
It does this by adding a header to each patch file, using the well understood
rfc822. I use Depends: and Description tags currently, but this could be
expanded for more features easily.
> Adam Heath has done a good job working arround some of our source
> package's deficiencies, but different people use different incarnations
> of his build system. This leads to a simple problem: there's no
> obvious way to gain access to the sources used to build the package.
> Some packages use 'debian/rules unpack', some use 'debian/rules
> stampdir/unpack', some use 'debian/rules $PWD/stampdir/unpack', some
> use 'make -f debian/sys-build.mk source.build', some use ... you get
> the idea. Having to scan (sometimes convoluted) debian/rules files
> looking for a way to unpack and patch the sources is a waste of time.
> The sys-build.mk variant is nicely documented... in
> debian/sys-build.mk. Others are nicely documented, too ... in
> debian/random_file. I don't care what filename you settle on for
> documenting this, as long as it's prefixed with README in caps. Get
> people to use the settled on filenames and methods and turn it into
> policy ("Packages using non-standard patch management system should
> document the fact in debian/README.whatever" or whatever makes the
> policy group happy)
I'd suggest README.building, myself.
Note, that there is another source patch system out there, in use by at
least glibc and gcc, that existed before dbs did. I have no connection with
that system(which is commonly known as dpatch).
As for DBS packages, the only official way to get at the source is thru
sys-build.mk. Anything else is unsupported. This includes those packages
that rename sys-build.mk to something else. We need to be consistent, and if
files start getting renamed willy-nilly, then they should no longer attempt to
call themselves DBS packages(sys-build.mk is the library interface, and as
such, should not be changed lightly).
As to hooking the targets in debian/rules into sys-build.mk, there are several
different ways. The one I tend to use, and recommend, is by using the
following makefile snipped in debian/rules:
==
...
debian/scripts/mk.vars: debian/scripts/vars
$(MAKE) -C $(@D) mk.vars
-include debian/scripts/mk.vars
BUILD_TREE = $(SOURCE_DIR)/$(TAR_DIR)
...
source.make: $(STAMP_DIR)/source.make
$(STAMP_DIR)/source.make:
$(MAKE) -f debian/sys-build.mk source.make
build: $(STAMP_DIR)/build
$(STAMP_DIR)/build: $(STAMP_DIR)/source.make
....
==
Note how this exports the target source.make, thru debian/rules.
Also, the targets in debian/rules are just convenient targets. They are not
the official way. The only official way is thru sys-build.mk.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: