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

Re: glibc and UNACCEPTs



On Wed, Aug 23, 2006 at 12:10:35PM +1000, Drew Parsons wrote:
> 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.

As said on IRC, I really don't want this in the Xorg packages. The penalty
for uploading to unstable by accident is minimal, as joeyh noted. The
actual fix is simple, and this problem occurs so infrequently for us that I
don't want to deal with it.

I'm glad that you simply made this echo a warning rather than die out, but
a warning isn't really going to provide any insurance unless you check the
full build log for every package you build. For X, this is unrealistic. All
this does is give us more code to carry around in xsfbs when the goal is
to prune the thing down to nothing.

 - David Nusinow



Reply to: