[pacman-dev] We've broken the bash

[Nezmer]

On Wed, Oct 13, 2010 at 05:40:44PM -0500, Dan McGee wrote:
> On Wed, Oct 13, 2010 at 5:32 PM, Allan McRae <allan at archlinux.org> wrote:
> > On 14/10/10 01:36, Dan McGee wrote:
> >>
> >> On Wed, Oct 13, 2010 at 10:12 AM, Allan McRae<allan at archlinux.org>  wrote:
> >>>
> >>> On 14/10/10 01:11, Allan McRae wrote:
> >>>>
> >>>> On 14/10/10 00:59, Dan McGee wrote:
> >>>>>
> >>>>> On Wed, Oct 13, 2010 at 9:54 AM, Allan McRae<allan at archlinux.org>
> >>>>>  wrote:
> >>>>>>
> >>>>>> On 14/10/10 00:11, Dan McGee wrote:
> >>>>>>>
> >>>>>>> I think this was alluded to a while back, but we are starting to show
> >>>>>>> some problems with our naming scheme and bash variable/function
> >>>>>>> naming
> >>>>>>> rules:
> >>>>>>>
> >>>>>>> /usr/bin/makepkg: line 1831: declare: `package_python-xlwt': not a
> >>>>>>> valid identifier
> >>>>>>>
> >>>>>>> With latest makepkg built from git.
> >>>>>>>
> >>>>>>
> >>>>>> Any chance of some more info on how to replicate? At least the
> >>>>>> pkgname line
> >>>>>> or even the whole PKGBUILD?
> >>>>>
> >>>>> Haha, my bad.
> >>>>>
> >>>>> wget http://aur.archlinux.org/packages/python-xlwt/python-xlwt.tar.gz
> >>>>> bsdtar xf python-xlwt.tar.gz
> >>>>> cd python-xlwt
> >>>>> makepkg
> >>>>>
> >>>>
> >>>> I can not replicate with 4.1.x or 3.2.x.
> >>>
> >>>                           ^ these are bash version....
> >>
> >> Hmmmmm. Build output attached, and here is the relevant part of this
> >> particular version of makepkg:
> >>
> >> 1825 # test for available PKGBUILD functions
> >> 1826 if declare -f build>/dev/null; then
> >> 1827   BUILDFUNC=1
> >> 1828 fi
> >> 1829 if declare -f package>/dev/null; then
> >> 1830   PKGFUNC=1
> >> 1831 elif [[ $SPLITPKG -eq 0 ]]&&  declare -f package_${pkgname}
> >>>
> >>> /dev/null; then
> >>
> >> 1832   SPLITPKG=1
> >> 1833 fi
> >
> > OK - I can replicate.   I forgot my makepkg-git package builds from my
> > working branch which had not been rebased to master after the last couple of
> > pushes.   But it turns out that was a good thing as there were only a couple
> > of patches that could cause this issue:
> >
> > 05f0a28932c1acab7a9ddb58435d69626dad54da is the first bad commit
> >
> > commit 05f0a28932c1acab7a9ddb58435d69626dad54da
> > Author: Nezmer <git at nezmer.info>
> > Date:   Tue Oct 12 02:23:16 2010 +0300
> >
> >    Use sysconfdir, localstatedir, BASH instead of hardcoded values
> >
> >    This applies to contrib/ files, our scripts, and the documentation.
> >
> >    Dan: fix 'make clean' in contrib/ directory.
> >
> >    Signed-off-by: Nezmer <git at nezmer.info>
> >    Signed-off-by: Dan McGee <dan at archlinux.org>
> >
> > ....
> >
> > which does this to the top of makepkg:
> >
> > #!/bin/sh -e
> >
> > which is bad...  even when we symlink that to bash as it starts in standards
> > compliance mode.  So you have not broken bash, you have broken configure!
> >
> > So looking at configure output:
> >
> >  checking for bash... /bin/sh
> >
> > and the configure check:
> >
> >  AC_CHECK_PROGS([BASH], [bash bash4 bash3], [false])
> >
> > So...  WTF?   It turns out the issues is that the BASH variable seems to be
> > used elsewhere and we have a naming conflict...
> 
> Oh man, this makes so much more sense. WTF, configure?
> 
> The shell itself sets this, try the following (which is what
> ./configure ends up doing):
> #!/bin/sh
> echo $BASH
> 
> I think I have a patch on the way...
> 
> -Dan
> 

My bad.

I would have caught this If I tested with Arch. This does not happen in
FreeBSD.

What is setting BASH exactly?