Deprecate dpkg completion#1639
Conversation
|
Sorry, just noticed now that this was against the now stale master branch, will rebase tomorrow against main instead and force push. |
|
We've already moved those files so that no conflicts happen. This PR seems to rename non-existent files, though I'm not sure why GitHub interface doesn't report conflicts. You base on an old commit between 2.13.0--2.14.0. If you intend to submit a patch to a certain version packaged in a distribution, could you please submit the patch to the package maintainer? If you intend to submit it here, could you please rebase the branch on top of the latest |
guillemj
force-pushed
the
pu/upstream-dpkg
branch
from
c9290bb to
f3997df
Compare
Right, see my comment which seems crossed at the same time as yours. I've now rebased it and force pushed. |
guillemj
force-pushed
the
pu/upstream-dpkg
branch
from
f3997df to
1daa158
Compare
scop
left a comment
scop
left a comment
There was a problem hiding this comment.
Another partial review round here, will need to look into this some more still.
As a general note, it seems this PR combines a number of changes in one commit that could have been split to multiple standalone/followup commits. It would be much easier to review it if was submitted as multiple logical commits (could review one commit at a time).
Because the single commit description needs an update anyway (conventional commits, dpkg vs non-dpkg system considerations / some of these are not deprecated everywhere), maybe look into splitting it, too?
There was a problem hiding this comment.
This should be named dpkg-reconfigure.bash -- it does not seem to do anything particularly useful when sourced on demand on debconf <TAB>, and on the other hand as it stands, it won't be sourced for dpkg-reconfigure <TAB>. Let's correct the top level comment while at it.
There was a problem hiding this comment.
I'll try to split it up, this was just carried over from what I had locally, and perhaps that was more of a draft at the time, and when I prepared it for submission it just all seemed to be tied together.
For the debconf name, I think I went with project name as grouping, but I see that does not make sense as you point out it would not trigger any auto-loading. Will rename.
There are at least to major implementations for the alternatives system. The original one from dpkg called update-alternatives used by dpkg-based systems and other systems that extract the update-alternatives code from the dpkg repository, and the one from chkconfig called alternatives and also exposed via a symlink as update-alternatives used mainly by RedHat adjacent distributions. These implementations have diverged in their interface, while they still share some common parts. To make it possible for dpkg to provide its own bash completion, the support for the alternatives system needs to be split. On dpkg-based systems the upstream completion will take precedence over the one provided by update-alternatives.bash. On chkconfig-based systems both alternatives.bash and update-alternatives.bash completions will be used.
The dpkg-reconfigure command is part of debconf, not dpkg. We need to split its completion so that we can deprecate the dpkg completion which is being taken over by the dpkg upstream project.
To make it possible for dpkg to provide its own bash completion, the support here needs to be namespaced. Because the dpkg completion provides public interfaces used by other completion scripts, the completion imported into dpkg will preserve those public functions for backwards compatibility for now. Ideally bash-completions would switch those functions into another file. Fixes: scop#694
guillemj
force-pushed
the
pu/upstream-dpkg
branch
from
1daa158 to
e076c75
Compare
3 participants
To make it possible for dpkg to provide its own bash completion, the support here needs to be namespaced. In addition, the support for dpkg-reconfigure (which is actually provided by debconf not dpkg), needs to be split.
Because the dpkg completion provides public interfaces used by other completion scripts, the completion imported into dpkg will preserve those public functions for backwards compatibility for now. Ideally bash-completions would switch those functions into another file. But that's left for later to be able to unblock the integration with the next dpkg upstream release 1.23.8.
Fixes: #694