[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Writing get-orig-source targets to conform with policy



Hello,

I have two questions. First question is;

Is it at all possible to write a get-orig-source target that calls an external 
script to handle generating the orig tarball?

The problem I'm facing is when the get-orig-source target is written like:
   get-orig-source:
        debian/external-script

It works fine under the package's top directory, but fails under any other 
directory, for instance, /tmp. I've looked over the GNU make documentation 
hoping to find a special parameter for finding the name of the make script 
ran, just how a shell script has "$0", but I've been unable to find one.

Second question is regarding a get-orig-source target I have for the package 
mediatomb. It goes like:

# Common variables used to ease maintenance of the get-orig-source target.
MEDIATOMB_TARBALL = mediatomb-0.10.0.tar.gz
MEDIATOMB_VERSION = 0.10.0
CORRECT_CHECKSUM = 2436c73de4ac5f3ba1575f7ee93a0430
# Haven't found a way to use this without running it twice
COMPUTED_CHECKSUM = $(shell md5sum $(MEDIATOMB_TARBALL) | cut -d ' ' -f 1)
get-orig-source:
	[ -e $(MEDIATOMB_TARBALL) ] || \
		wget http://downloads.sourceforge.net/mediatomb/$(MEDIATOMB_TARBALL)
ifeq ($(CORRECT_CHECKSUM),$(COMPUTED_CHECKSUM))
	@echo Generating orig tarball
	tar -xzf $(MEDIATOMB_TARBALL)
# Removing some problematic files from upstream
	rm mediatomb-$(MEDIATOMB_VERSION)/tombupnp/upnp/src/inc/upnp_md5.h
	rm mediatomb-$(MEDIATOMB_VERSION)/tombupnp/upnp/src/uuid/upnp_md5.c
#####
	tar -czf mediatomb_$(MEDIATOMB_VERSION).dfsg1.orig.tar.gz \
		mediatomb-$(MEDIATOMB_VERSION)
	rm -rf mediatomb-$(MEDIATOMB_VERSION)
	rm $(MEDIATOMB_TARBALL)
	@echo done.
else
	@echo Checksum mismatch. Correct checksum is $(CORRECT_CHECKSUM).
	@echo Computed checksum was $(COMPUTED_CHECKSUM).
	exit 1
endif

The problem here is that the get-orig-source target has to be run twice before 
the checksum passes (unless you happen to have the file in the current 
directory already). Is there any way around this?

The second problem is why I more interested in finding a way to handle 
external scripts that conforms to Debian Policy where it explains, "This 
target may be invoked in any directory." 

-- 
Regards,
Andres


Reply to: