New comment by Hoshpak on void-packages repository

https://github.com/void-linux/void-packages/pull/23601#issuecomment-659617133

Comment:
> *@ahesford* requested changes on this pull request.
> 
> I think we will always have difficulty with files that might contain spaces in 
> the name, because we will not be able to distinguish a file named |File with 
> spaces| in |$ignore_in_usr_share| and three separate files named |File|, |with| 
> and |spaces|. Using an array instead of space-separated strings avoids this, but 
> gets clumsy in the template (if we allow arrays in |ignore_in_usr_share|, why 
> not for any other variables?).

I think the general consensus up to now was to keep arrays out of
xbps-src. It will make the code less portable but we use a lot of
bashims already and the general assumption is that it will be run with
bash. Personally I just dislike how arrays are handled in bash and
usually tend to rather rewrite a script in python than having to deal
with them.

> It might also be nice to support directories in |ignore_in_usr_share| so we can 
> do things like |usr/share/qemu/firmware| instead of listing each file, but that 
> involves a second test and a bit of thought.

In the case of qemu there are just two files which make the hook fail. I
don't know if there are packages with a lot of files which would require
exceptions though.

> |[[ ${ignore_in_usr_share} != *$(basename "$I")* ]] |
> 
> to the match operator would be consistent with with match tests in the 
> build-helpers.
> 
> Regardless, the argument to |basename| should be quoted in case the file has 
> spaces in the name.

Thanks, I changed the check as you suggested and verified that it now
works for files with spaces.

> Also, why bother stripping out |PKGDESTDIR| from |file| if we are feeding it to 
> basename anyway?

Just an oversight on my part. I removed it.