Re: glibc and UNACCEPTs
Denis Barbier wrote:
> On Tue, Aug 22, 2006 at 11:08:49AM +0200, Andreas Barth wrote:
> > * Drew Parsons (dparsons@debian.org) [060822 11:04]:
> > > 2) [technical] Remove the single point of failure by adding a
> > > Distribution: field to debian/control, say. The package will be
> > > rejected if the two fields in control and changelog do not match.
> >
> > or just make dpkg-buildpackage fail if that happens (or rather
> > dpkg-genchanges), which isn't too hard to achive actually.
>
> Yes, I added the following lines in debian/rules
> # Do not accidentally upload into unstable
> dpkg-parsechangelog | grep "^Distribution:" | grep -q -v unstable
> for that purpose in the glibc experimental branch.
Your version requires this line to be deleted for unstable and then
added again for any future experimental work.
I prepared an alternative snippet by which the test can remain, and
switched off by an explicit extra variable saying simply "yes". This
is an extra make rule to go in debian/rules (or xsfmb.mk, for the XSF):
# Before building, check we're not making an accidental upload to unstable
.PHONY: test_stable
test_stable:
@if [ "x$(UPLOAD_TO_UNSTABLE)" != "xyes" ] && \
[ -n `dpkg-parsechangelog | grep "^Distribution:" | grep -q -v unstable` ]; \
then \
echo "POSSIBLE MISLOAD TO UNSTABLE!"; \
echo "You have set the distribution to 'unstable' in debian/changelog"; \
echo "but have not set UPLOAD_TO_UNSTABLE=yes in debian/rules"; \
echo "Please fix this before proceeding."; \
exit 1; \
fi
It would be applied when building:
e.g.
build: test_stable patch build-stamp
instead of
build: patch build-stamp
Unstable uploads would then be permitted by placing
UPLOAD_TO_UNSTABLE=yes
in debian/rules.
It would, of course require the 'yes' to be replaced by 'no' and vice
versa, as you go between unstable and experimental. Since we don't
always have ongoing versions developed in experimental, it may not be
worth the bother. But there it is if anyone wants it.
Drew
Reply to: