Fix regression in install-data-hook, support sourcing bash_completion.d from /usr/share/ and move ours #1399
Conversation
It no longer matches bash_completion so it was not substituting for the actual compatdir due to a refactor. Follow-up for cdd8a15
|
This is related to the discussion at #1329 (comment). I don't think-
I'm not familiar with the recent movements in distributions, but which distributions are you referring to? For example, |
Sure, I've changed it to
For example in Debian we recently moved most program's own shell completion scripts from /etc/bash_completion.d/ to /usr/share/bash-completion/completions/ You can find a list of similar efforts at uapi-group/specifications#76 |
This doesn't seem to be the official decision led by the maintainers of Debian's base system (that covers the basic parts of |
There was a problem hiding this comment.
I think one thing I should point out is that the /etc/bash_completion.d is anyway for backward compatibility (although there is a subtlety as discussed in #1329 (comment)). Then, a naive question would be whether we should introduce incompatible changes in the code kept for backward compatibility (which doesn't seem to make sense at first glance). If it breaks the compatibility, we could also argue that compatdir should rather be removed.
- To completely get rid of
/etc/bash_completion.d, all the programs that provides completion scripts with the old API need to be updated or adjusted in the packaging stage. - If the change is only applied at the packaging stage of distributions (without updating the scripts to use the new API), the package maintainers can always adjust the location of the scripts (including
000_bash_completion_compat.bash) by setting a system defaultBASH_COMPLETION_COMPAT_DIR(or applying a patch tobash_completion). - If an upstream project of a specific command has a chance to change the location of the default install location from
/etc/bash_completion.dto another place, it should rather update its completion script to use the newer API and put it in/usr/share/bash-completion/completions.- In this context, if the project author sets up the installation of the completion script using autoconf or cmake following our
README.md, if we change the compatdir in pkg-config, the installation location should automatically be adjusted even if the project is not actively maintained. In this sense, changing the default location ofcompatdirnow still has some effects. A little concern is how widely our pkg-config settings are installed in the system in distributions.
- In this context, if the project author sets up the installation of the completion script using autoconf or cmake following our
Even if this PR doesn't have much benefits in the practical situations, I think I can accept the PR.
Yes, I mentioned them as separate and independent examples as I thought you were looking for more than one occurrence, sorry for the confusion |
In distributions we are in the process of moving data shipped by upstream projects to /usr/ and out of /etc/, as the latter is really meant to be for local changes, not for upstream projects to ship programs/data. Add support for sourcing compat scripts from /usr/share/bash-completion/compat/ together with /etc/bash_completion.d, and move 000_bash_completion_compat.bash to the former.
My intention here was to keep backward compatibility intact - the existing directory is still checked for scripts. Do you see any use case that would be broken by these changes? |
|
My gut feeling about this is that compatdir being a deprecated thing, we should consider functionality related to it as frozen, including not making it any easier/cleaner to use. We don't mention compatdir being deprecated too prominently though, which is something we could improve. I'm not sure if there's any other mention of it at the moment than Lines 185 to 186 in 98207f4 |
We still need it to ensure our completion scripts work with older versions, and likely will for many years, so I'd be a lot happier with this change included. That way we can build usr-only images where everything works out of the box. Thanks. |
Just to confirm I understand correctly, older versions here refers to bash-completion < 2.0 (which was released in Jun 2012)? |
Sorry, let me add more details: in this case I am explicitly referring to We use it here: https://github.com/systemd/systemd/blob/main/shell-completion/bash/systemd-run#L51 |
|
I'm still unsure about whether the provided reasons make sense. If a distribution want to put the compat directory in another location, the distribution can always set
I think the distribution can set
Actually, they are not officially deprecated.
This is one of the problems of the current setup. This is discussed in #1329 (comment). Originally,
For this reason, we still recommend external completion writers to use API v2 (which was introduced in bash-completion-2.0). When you write completion settings and don't want to switch between two APIs, v2 and v3, depending on bash-completion's version, you are recommended to use API v2. We intend to recommend API v2 for about ten years. See #1328 for details. I wrote that, forgetting about the provided reasons, I could accept the PR, but I'm actually neutral about accepting or rejecting the PR. As I already discussed in #1329, I believe we want to sort out the directories. In the process of re-arranging the directories, I guess we would finally want to introduce another "compat" directory, so I thought we might introduce the
It may be better to discuss #1329 at the same time, which would take time. Then, we might want to make a decision on this PR after the next release. Another thing is that, as I discussed in #1399 (review), the change in this PR seems harmless to me (though I'm not sure if there are actual benefits for the context provided by the OP). We still look at |
Having to do local patches or modifications is strictly worse than simply fixing the behaviour for everyone out of the box. Everyone needs to notice, know and ship the changes. There are no downsides to just changing it upstream, and only advantages. Even from the design point of view, shipping code in /etc/ is wrong and has always been wrong:
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s07.html This is runnable code, so it does not belong in /etc/ according to all standards and specifications.
But without 000_bash_completion_compat.bash, it's not possible to use
There are. As already mentioned, we are already building usr-only images in many use cases. All the upstream code and data should be in usr.
Yes indeed, as mentioned I made sure not to harm backward compatibility. Files shipped in /etc/ have precedence and it looks there first. |
I generally appreciate the idea of organizing I think we can agree that we should organize it in some way, but the concrete setup of how it should be reorganized needs to be determined by the community. So far, I do not see any major movements in distributions to carry it out in a collective way. The suggested changes seem to be promoted only in an organization called UAPI. They raised discussions in Debian, but they didn't seem to be fully welcomed. Otherwise, there don't seem to be public discussions. In addition, I'm not even sure that this decision to move this specific We should wait until the consensus is formed to avoid unnecessary switching forward and backward. So far, most distributions are satisfied with the current setup. If one wants to move away from the current way of using
So, in your point of view,
So you haven't read the FHS specification carefully. You've dropped the footnote link [2] in the quoted explanation of
The directory is meant for backward compatibility, but the file is not. This is what I explained in my previous reply:
|
I really don't think that's true. I see no evidence of anybody intentionally wanting to ship upstream code in /etc/, all occurrences are just where it happens to be for no reason at all, other than legacy setup just having been like that. Do you have any evidence of that?
It doesn't? Backward compatibility is kept, intentionally, any existing script will still be loaded from the previous location too and work as expected.
There is. We do, and anybody else doesn't really care one way or the other. Every distribution that matters adopted usr-merge for this (and many others) reason.
No, we didn't. Please do not mistake some random thread by some random person in some random mailing list as "discussions" - debian-devel is not for discussions, it's just random spam by random accounts, and it's best ignored. Look at changelogs if you want an actual idea of what's going on there.
As above, this already happened for those who care - and those who don't, simply don't mind one way or another anyway
Yes! One of the many, many wrong things with it
I have - it's a footnote for a reason. It's an outdated concept that vendor-provided scripts should be editable locally - this hasn't been the case for a really long time. Or are you saying that you expect random users to do personalized, local modifications to
Then why is the file itself called "compat"? |
|
Look, I just noticed two bugs while building images and wanted to be a good citizen, and provided a fix for both, so that things can work out of the box in our use cases, without negatively affecting anybody. If you really feel so strongly about it because of how things happened to organically get mashed together in the 1980s, then feel free to just close this, and keep the package broken for such use cases. It just means it will get either worked around, or most likely, dropped as non-functional. I'll just hit unsubscribe and stop replying now, thanks for your attention so far. |
|
This PR has been full of deception from beginning to end, and the OP has finally rage-quitted. They pretended to be authoritative and tried to force us to follow them, but they haven't provided any reference except for a UAPI issue. I appreciate the goal of the OP, but their investigation and survey were insufficient. Their arguments lacked knowledge about modern setups (as well as the historical ones) and were based on misunderstandings about basics. I won't reply to them because they don't hear us anymore (but not because I don't have replies). I'll just pick the first commit. |
I don't agree with the accusation that his retreat from this discussion is fueled by "rage". IMO abstaining from a discussion where one notices that the two parties are in an "immovable object vs unstoppable force" situation to spent the time where it is better invested is very reasonable.
They are a Debian maintainer (and UAPI member) which carries a bit of weight but I am not sure if he claimed to be an "authoritative" entity himself. For that he referred to the Spec of the UAPI Group which I would personally call some kind of authoritative source, similar to freedesktop.org. They represent a multitude of interest groups which lay down current, de-facto standards or develop future standards, and have members from many Distros, companies and projects.
Please allow me to add a bit more to the surves/investigation: You might not have found too much information about this config thing because not everything is necessarily written down, and even if it is, may not be indexed by Google (e.g. Fedoras Pagure is badly represented). Things like this UAPI spec are often though out in-person, in this case primarily at the "Image-Based Linux Summit" as discussions are easiest that way. One of the initiators of moving vendor config to Parties represented during those summits (2022-2024 combined) where among others: Ubuntu, Debian, Fedora, Arch Linux, SUSE, NixOS, some hyperscalers, and some smaller distros. Of the listed distros it was often the working group for immutable variants that were present but not exclusively. If these distros all come forwards and create a specification for how configuration should be handled I think it should be given weight.
You cannot expect that everyone has a deep understanding of your project. Luca saw a package where he wanted to improve the status quo to advance the adoption of the UAPI spec and created a PR. He may have already working with this project before in the context of systemd but that is only slight exposure at the surface level. One should not expect him to know which exact API is deprecated, planned to be deprecated, or is the way forward. When it comes to modern setups I also agree with him. I too have deployed a few immutable/image based appliances which boot up with only You also stated that the proposed changes seem harmless to you - and they are very small. In lie of having every distro carry this as a downstream patch it seems reasonable to me to accept this. |
|
To clarify first, I didn't reject the suggestion, though the OP seems to claim in the UAPI thread that we've rejected it. From the provided information, I couldn't judge whether the provided reasons make sense. The OP didn't provide any references for the relevant details, despite implying that something about
Thank you for the information. Those kinds of links are what I expected. If any, can you point me to where to look at what's going on with
Are BSD distributions included in this list? I can understand it even if the BSD distributions are excluded from the UAPI because the UAPI seems to target Linux. However, bash-completion targets also BSD, and we are interested in what the UAPI thinks of the different setups of
Based on the arguments provided until now, it seems to me that the current movements on
The size of the code change is irrelevant now. We are supposed to carefully consider the impact on users and maintainability as maintainers. We are not supposed to blindly accept the PR, no matter how small the code change is.
I'm unsure whether the statement that every distro applies the same patch is correct. If the symbolic links in Off topic
The OP hasn't explicitly stated that, but the way of writing has been misleading. The OP initially appeared to be a representative of distributions in general, but then a representative of Linux distributions, then a representative of the Debian distribution, then a representative of Initially, this PR started with "In distributions we ...", which sounded as if the OP is a representative of some distributions of operating systems. The distributions were not precisely specified, but This is strange. Also, the PR title appears to imply that the main purpose is to fix a trivial regression, but the actual purpose is to propose a change in the usage of
I agree that one can say that UAPI and FHS specs have some kind of authority, but what is unclear is if the OP was really a representative of those groups or merely a member. Without references, I can't tell e.g. whether the core Debian developers are members of the UAPI and whether the OP's claim matches a consensus under the UAPI. (I actually doubt the general consensus in Debian from the limited information.) I see that there are indeed movements on reorganizing
Yes, that is the problem, but in this case, I expect it to be the PR submitter's responsibility to provide enough information and references when requested. The OP didn't provide any links but the UAPI thread.
I didn't talk about the knowledge in bash-completion. I talked about the basic knowledge related to Unix and standards. The OP claimed that the shell scripts are executable binaries. The OP claimed that the footnotes in specifications are what are discouraged. The OP didn't know about the traditional configuration of Comments on the last reply from the OP
I talked about a different setup, but the different setup doesn't necessarily require installing upstream codes in
I wrote "to comply your suggestion". You are right that the change of this PR doesn't break the existing completions. However, my point is that even if
I expected references to discussions about
The first thread that I linked in #1399 (comment) explicitly mentioned the UAPI as the group behind it. Another thread is started by the OP of this PR. The above statement implies that the OP is one of random accounts posting random spam to the Debian mailing list. This is strange. If that's true, I need to be careful about the possibility that this PR is also spam from random accounts in the UAPI (instead of an official representative of the UAPI).
To write it down explicitly, the directory is meant for backward compatibility with the deprecated interface v1, but the file is for the compatibility with v2, which hasn't been deprecated. Anyway, the file |
I am not connected to UAPI in any way apart from following and commenting on some of their issues and deploying images which benefit from their specs.
Ideally For more complex systems there is the argument that config files in
Not to my knowledge but adopting the config spec does not break compatibility with them.
Apart from the layering, priority, merging aspects of the config spec which applies less to bash-completion the most important aspect is that deploying/updating systems becomes easier. This is very important in the context of image-based deployments (those who update e.g. whole partitions instead of using a package manager) but also in other contexts. Let me expand on that:
Point 3 is relevant for all distros, 1 only for a selected few because support is still somewhat bad (openSUSE and Fedora already can do this for the most part, Debian and Ubuntu fall apart last I tested), 2 is relevant for distros like Ubuntu Core, Fedora Silverblue/Kinoite, NixOS, PostmarketOS, etc.
They should work but then something would have to create them, i.e. you would need to ship a tmpfiles.d config. The use-case you should have in mind is that booting with an empty /etc should eventually work out-of-the-box.
GitHub seems to have swallowed both of these when quoting/replying, I'll leave them be if that is fine with you unless you would like some comments on that |
In distributions we are in the process of moving data shipped
by upstream projects to /usr/ and out of /etc/, as the latter
is really meant to be for local changes, not for upstream
projects to ship programs/data.
Add support for sourcing compat scripts from /usr/share/bash_completion.d/
together with /etc/bash_completion.d, and move 000_bash_completion_compat.bash
to the former.