dpkg integration upstream

[guillemj]

Describe the feature/solution

I'd like to add bash-completion support in dpkg upstream, I've got a branch starting work for that. The problem is that there's already some support for it here, but mixed with completions for dpkg-reconfigure, which is (very confusingly) not a dpkg program, but a debconf one. So to avoid stomping over the support for the debconf command, first it would need to be split into its own file. The dpkg support can remain I guess, for a transitional period, until people have upgraded to a dpkg version that ships with the completions.

I'm not sure how you handle upstream adding support when there was some already present here though?

Maintenance (please complete the following information)

• [ ] This is a request for new completion
• [ ] Link to upstream project query about shipping the completion:

[scop]

Cool :+1:

The general process of starting to give precedence to external completions is so that we make room for them by renaming the completion file we ship so they begin with an underscore; bash_completion's loader prefers ones without it and falls back to ones that have it. At the same time, we add a deprecation comment to the one we still ship. An example of this is at https://github.com/scop/bash-completion/pull/535

Splitting dpkg and dpkg-reconfigure requires a bit of thought because the latter uses the _comp_dpkg_installed_packages helper. If splitting normally we'd just make dpkg-reconfigure completion call it with _xfunc from the dpkg completion file, but since we're about to deprecate the dpkg completion, we shouldn't be calling things from it from non-deprecated completions. Perhaps it's as simple as just doing the process here the other way around, even if the helper does feel a bit misplaced that way.

[guillemj]

Hey!

So, I ended up having a go at this (see referenced commit above, but could probably submit it as a WIP MR maybe) as otherwise I'll not be able to start integrating completion support upstream, and I'm indeed stuck on what to do with the dpkg generators, because these are used by not only the dpkg-reconfigure completion which I've split into a debconf file, but also apt-build, apt-get and aptitude completions, and I'm not sure how to proceed TBH.

My initial thinking was that perhaps these functions should be moved into a new file (and not the new debconf one), because if say debconf absorbes support upstream then we'd be at the same impasse, so if there was say an internal-dpkg or comp-dpkg file that could be loaded, or whatever other namespace that might make sense for this kind of shared code could live in. Because even if all current users within bash-completion were to get upstreamed, these functions are part of its API (AFAIUI), so they would still need to be provided I guess. But that looked like it might require some support in the core completion code? Also wouldn't that break external users that expect these functions to live in that specific file?