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