On Thu, Sep 08, 2011 at 03:38:39PM +0200, Raphael Hertzog wrote:
> Hi Josip,
>
> On Thu, 08 Sep 2011, Josip Rodin wrote:
> > Instead, it is important to retain the age-old idea that the rules file has
> > its own calling convention (an API) that isn't linked to one specific
> > implementation and is instead properly specified in Debian policy, allowing
> > developers some common-sense leeway and the ability to adjust the API if and
> > when necessary.
>
> The API is not the only thing to take into account. Using anything else
> than make is unexpected for most other developers (some of them who might
> have to NMU your package at some point).
I agree, but that argument goes both ways - we already allow developers to
use obfuscated makefiles, which has the analogous potential for difficulty.
> > Heck, even the typical dh(1) debian/rules file (so typical I pasted it
> > straight from its manual page):
> >
> > #!/usr/bin/make -f
> > %:
> > dh $@
> >
> > does not strike me as better than a shell script such as the one used by
> > leave's debian/rules file - in fact it's seems more opaque and needs more
> > documentation/knowledge to figure out in what way does this follow
> > the rules set out in the policy.
>
> Yes, but it's also not worse than having to read the sources of a shell
> script.
Ahem, so I must quote it:
#!/bin/sh -e
tmp=`pwd`/debian/leave
if echo $DEB_BUILD_OPTIONS | grep -vq noopt; then
optflag="-O2"
fi
if echo $DEB_BUILD_OPTIONS | grep -vq nostrip; then
stripflag="-s"
fi
case "$1" in
build)
test -f leave.c || { echo not in the right dir\!; exit 1; }
test -f leave || { cc -g $optflag -Wall \
-D__COPYRIGHT\(x\)= -D__RCSID\(x\)= \
leave.c -o leave
}
# used to have 'pmake CFLAGS="..." leave' here, but why?
;;
clean)
test -f leave.c || { echo not in the right dir\!; exit 1; }
test `id -u` -eq 0 || { echo "don't have (pseudo-)root!"; exit 1; }
rm -f build-stamp leave leave.o leave.cat1 debian/files debian/substvars
rm -rf $tmp
;;
binary-arch|binary)
test -f leave || $0 build
test `id -u` -eq 0 || { echo "don't have (pseudo-)root!"; exit 1; }
rm -rf $tmp
install -d -m 755 $tmp/usr/bin $tmp/usr/share/man/man1 \
$tmp/DEBIAN $tmp/usr/share/doc/leave
install $stripflag -m 755 leave $tmp/usr/bin
gzip -c9 leave.1 > $tmp/usr/share/man/man1/leave.1.gz
gzip -c9 debian/changelog > $tmp/usr/share/doc/leave/changelog.Debian.gz
install -m 644 debian/copyright $tmp/usr/share/doc/leave
dpkg-shlibdeps $tmp/usr/bin/leave
dpkg-gencontrol -isp -P$tmp
chown -R root.root $tmp
chmod -R g-ws $tmp
dpkg --build $tmp ..
;;
binary-indep)
# do nothing, successfully!
exit 0
;;
*)
echo unknown option: $1
exit 1
;;
esac
Is the compliance with policy easier to read from the obfuscated makefile
example at the top, or from the trivial shell example above?
I wouldn't actually definitively answer that question, it's probably a
matter of personal vgrep to some extent, but I'm certain the conclusion
"makefile syntax, obfuscated or not, is sufficiently better than all
others, that all others are hereby forbidden" doesn't make any sense.
> And still, this is a Makefile so you can quickly reuse Makefile snippets
> that others have been writing to add support for supplementary targets
> (like get-orig-source) or even to influence the environment (like the
> Makefile snippets that dpkg 1.16.1 is going to provide).
Same can work for pretty much any other similar language.
If we didn't really need these snippets in all packages so far, it's hard
to argue they're relevant as a reason to ban all languages that don't
instantly support them.
> So I really don't understand why you insist on keeping debian/rules
> as a shell script. Moving it one level deeper in the process tree
> does not strike me as a big performance/readability loss, certainly not
> one worth spending the time of tech-ctte members on such a case.
So you want me to satisfy the letter of the policy but break its spirit? :)
> > The whole idea that we're changing something in the build-arch handling
> > is a nice supporting argument for my idea that we don't have a reason to
> > hardcode make - the fact that we control the API means that we are able
> > to make this decision, rather than having to adjust to whatever some
> > semi-random program does.
>
> If you ignore all transitions constraints, sure. At the same time, Debian
> decided debian/rules must be a Makefile and you're not adjusting to cope.
No, "Debian" did not decide to explicitly ban non-shell rules files at any
point in time, it was a leftover from a text conversion that never got
fixed.
The way the Packaging Manual was written was certainly with makefiles in
mind, it explicitly said that a rules file is a makefile and used the term
"target" and similar. But the description of the API was pretty carefully
restricted to the feature set independent of make's intricacies.
It remained so until the present day, and it works in practice. So why
break it?
> Why should you better accept another API design compared to an already
> existing policy requirement?
I can't parse that sentence, sorry, can you rephrase?
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
