Control: tags -1 + patch

Hi, Sergio,

<3 S2 <3 S2

On Thu, 30 Jul 2020, Sergio Durigan Junior wrote:
> 
> So, here's the thing.  We can't blindly rely on debhelper's
> filedoublearray anymore, because of the problem you guys pointed out
> above.  Which means that bash-completion will probably have to have its
> own stripped-down, poor-man's version of filedoublearray.  Actually,
> given the way dh_bash-completion works, it should be enough to have a
> function that tries to determine whether the file being examined is (a)
> a bash-completion script, or (b) a file-list.  If (a), then the file
> itself should be installed.  If (b), then we install each file listed in
> it.

I really like this approach. It lets filedoublearray be free to do
whatever it wants, while still working for bash-completion on the file
list case.

> In order to hack this new function I used a little bit of what
> filedoublearray does in the beginning, and then I crafted a few regexes
> that will perform a "heuristic" to see if we catch some well-known bash
> constructions in the file.  If we succeed, then just assume that the
> file is a bash-completion script and be done with it.  Otherwise, it's
> (probably) a file-list.

I like the heuristic you came up with; it should be enough to cover all
completion files I have seen so far and it is so well-documented that
it should be easy to fix if problems show up.

> Now, in order to test this approach, here's what I did (inside a schroot
> session):
> 
> - Go to sources.d.o, look for all the packages that depend on
>   bash-completion.
> 
> - Download the list, iterate over it and do an "apt source" on all of
>   them.
> 
> - Check for a few interesting cases in this list.  Examples I could find
>   are: consul, cargo, caffe, 2ping, xkcdpass, virtualenvwrapper.
> 
> - Enter their directories and perform a "dh_bash-completion -v".

Thanks for being so careful about testing and for sharing the steps
with us. I'll adopt it for my workflows.

> As far as I have tested, everything works OK.  Of course, this is a
> heuristic approach and it is possible to craft a problematic file that
> will cause an error, but it's better than what we have now, IMHO.

+1

I have tested a couple of reverse-build-dependencies of
bash-completion. Most of them use file lists and the patched debhelper
script works as before when compat level is updated to 13. I also found
one package that has a proper completion snippet (pidcat), which also
works correctly with the patched debhelper script and debhelper 13.

I haven't tested all reverse build dependencies, though. The list is
too large.

> BTW: while I was hacking I had another idea, which is to use a
> try...catch block around filedoublearray and see if it "throws" anything
> like ".*cannot resolve variable.*", but that doesn't really work: if the
> error is triggered, it might mean that we're dealing with a
> bash-completion script, *but* it might also mean that the file-list file
> is broken (e.g., referencing a wrong or non-existent variable), which
> means that we would need to perform some kind of parsing to determine
> what's really happening anyway (assuming that we want to do a good job
> at detecting the error).

thanks for sharing. :)

> Hopefully this will help.  I'm not tagging this as "+patch" because I'd
> like to hear your opinions first.

Now tagged.

I'll incorporate this change to the repository, do a little more testing,
then upload to unstable. May I set git commit authorship to
"Sergio Durigan Junior <sergi...@debian.org>" ?


Cheers,
Gabriel

Reply via email to