Guillem Jover wrote: > Due to a bug in lintian the brace-expansion-in-debhelper-config-file > warning (introduced in 2.1.4) did not trigger until lintian 2.5.2, > which made it difficult to realize there was a problem with it at > all until recently. > > dpkg started using brace expansion [0] due to a change in debhelper > 4.9.5 which made wildcards expanding to nothing to error out. > > I don't know what made Raphaël think that was supported, maybe just > trial and error, but it seems like a rather elegant “solution”. In any > case I don't want to justify the fact that dpkg is using undocumented > behaviour (I'm aware of #480868 and #480939) and that debhelper > should support it because packages are using it. Just wanted to request > if this could become a sanctioned behaviour because it truly seems > useful and elegant. In case you still don't want to support it, could > you consider instead to add an option to not fail on wildcards expanding > to nothing, so that we can revert to our old debhelper config files, > w/o needing to move most of the install files to debian/rules?
It doesn't seem very elegant. It relies on a quirk of perl's glob
engine.
Notice that, {foo*,otherfile*} will only succeed as long as one of
the interior globs match; if both globs fail it will stop. It's
not really doing what you want; what you want is available via
DH_COMPAT=4.
And if that's tweaked to {foo,otherfile*} it will, instead of only
expanding to existing files, now it always expand to "foo" even when
that doesn't exist.
And then there's the way that it conflicts with the proposed syntax
for ${VAR} expansions in debhelper config files..
--
see shy jo
signature.asc
Description: Digital signature
