Problem 1 (#1918348, comment #14 in #1907800): The current solution for vi/vim (subshells as aliases) shows in process viewer as logical conjunction of commands, which isn't good for reading. Problem 2 (#1910210): csh doesn't have 'command' as builtin command, so it needs to be explicitly installed or to be changed to 'which' again. Problem 3 (based on communication with praiskup): The shell aliases don't work with sudo, so you still get command not found if you use the command which isn't installed right now. Solution: Remove all shell scripts and let the alternatives do the job - alternatives will set up the correct vi/vim based on if vim-enhanced or vim-minimal is installed. It will happen during %preun and %post scriptlets for installing/removing, and %triggerin for upgrading. My current problem is how to setup alternatives during upgrade via %triggerin scriptlet.
*** Bug 1910210 has been marked as a duplicate of this bug. ***
*** Bug 1918348 has been marked as a duplicate of this bug. ***
(In reply to Zdenek Dohnal from comment #0) > Problem 1 (#1918348, comment #14 in #1907800): > The current solution for vi/vim (subshells as aliases) shows in process > viewer as logical conjunction of commands, which isn't good for reading. > > Problem 2 (#1910210): > csh doesn't have 'command' as builtin command, so it needs to be explicitly > installed or to be changed to 'which' again. > > Problem 3 (based on communication with praiskup): > The shell aliases don't work with sudo, so you still get command not found > if you use the command which isn't installed right now. > > Solution: > Remove all shell scripts and let the alternatives do the job - alternatives > will set up the correct vi/vim based on if vim-enhanced or vim-minimal is > installed. It will happen during %preun and %post scriptlets for > installing/removing, and %triggerin for upgrading. > > My current problem is how to setup alternatives during upgrade via > %triggerin scriptlet. Other packages uses %postinstall and %preuninstall which runs also during upgrades. See for example rpm -q --scripts xorriso rpm -q --scripts genisoimage rpm -q --scripts wodim rpm -q --scripts ssmtp rpm -q --scripts spax rpm -q --scripts pax rpm -q --scripts links rpm -q --scripts links rpm -q --scripts fakeroot rpm -q --scripts sssd-client rpm -q --scripts cups-client rpm -q --scripts binutils rpm -q --scripts NetworkManager rpm -q --scripts groff rpm -q --scripts mailx rpm -q --scripts man-db rpm -q --scripts man-pages rpm -q --scripts mercurial-py2 rpm -q --scripts mercurial-py3 rpm -q --scripts p11-kit-trust rpm -q --scripts qt rpm -q --scripts qt5-qtbase
Ok, so alternatives are no-go right now because they don't work for immutable Fedoras, so I introduced the vim-wrappers subpackage (conflicting with older vim-enhanced and vim-minimal), which will ship shell scripts vi, vim and view. Those scripts run vi.origin and vim.origin binaries, which are the original vi/vim binaries, depending on which one of them is installed. The expected behavior is: 1) to run 'vim.origin' if it is installed regardless what command did you use ('vi' will start 'vim.origin', 'vim' -> 'vim.origin', 'view' -> 'vim.origin -R'). This behavior is in vim rpms for long time. 2) to run 'vi.origin' if it is installed and 'vim.origin' is not regardless what command did you use ('vi' -> 'vi.origin', 'view' -> 'vi.origin', 'vim' -> 'vi.origin'). The 'vim' -> 'vi.origin' behavior was added several months ago based on users feedback that they want just edit a simple text and don't care about vi/vim differences in features. I'm putting this behavior in as it is till there will be any complaints - in case of complaints I will probably add a check for env variable, which will enable this behavior and the users which want it will need to enable it, but it is only possibility for now... Both behaviors are now applied to root user and can be used with 'sudo'. The users will need to restart their shell after this update, because the old aliases will be loaded until shell is restarted. 'ps aux' will show '/usr/bin/vim.origin' and '/usr/bin/vi.origin' with this solution. Here is the copr build with the change - https://copr.fedorainfracloud.org/coprs/zdohnal/vim/build/1929196/. Please test the solution and leave a feedback.
I like this variant a lot, it works naturally in all situations for me. Thanks! Some cosmetic notes: - It might be sightly nicer if we moved /usr/bin/vi.origin to /usr/libexec/vi, 'ps' command would show just 'vi', not 'vi.origin' - /usr/bin/vi should be a symlink to /usr/bin/vim - the 'vim-wrappers' existence IMO doesn't bring any benefit, it would be just OK if the wrappers were shipped both in vim-minimal and vim-enhanced
> 1) to run 'vim.origin' if it is installed regardless what command did you use ('vi' will start 'vim.origin', 'vim' -> 'vim.origin', 'view' -> 'vim.origin -R'). This behavior is in vim rpms for long time. > This behavior is in vim rpms for long time. This is probably happening since F32 (F31 runs vi when both are available). Perhaps we could check for the '$0' variable in that script, and fallback to alternative variant (vi->vim or vim->vi) when the requested editor isn't available.
(In reply to Pavel Raiskup from comment #5) > I like this variant a lot, it works naturally in all situations for me. > Thanks! > > Some cosmetic notes: > - It might be sightly nicer if we moved /usr/bin/vi.origin to > /usr/libexec/vi, > 'ps' command would show just 'vi', not 'vi.origin' Sounds good, I'll change that. > - /usr/bin/vi should be a symlink to /usr/bin/vim Sounds good, it will save the space. > - the 'vim-wrappers' existence IMO doesn't bring any benefit, it would be > just OK if the wrappers were shipped both in vim-minimal and vim-enhanced Actually, I introduced the subpackage to make the spec more readable (IMO) - now I have both related conflicts in one place, shared files in one place and the original subpackages require the new subpackage. If it brings any potential problems, please let me know. Right now it looks good to me. (In reply to Pavel Raiskup from comment #6) > > 1) to run 'vim.origin' if it is installed regardless what command did you use ('vi' will start 'vim.origin', 'vim' -> 'vim.origin', 'view' -> 'vim.origin -R'). This behavior is in vim rpms for long time. > > This behavior is in vim rpms for long time. > > This is probably happening since F32 (F31 runs vi when both are available). Hmm, I see the commit introducing this behavior in 2016 (approx Fedora 23). The commit: https://src.fedoraproject.org/rpms/vim/c/82a60bffab4889ff1e5881a5e54c7c30ab5f0f63?branch=master but it doesn't work if you are logged as an user with id lesser than 200 or with sudo. Or it hasn't been working at all since then :) . > > Perhaps we could check for the '$0' variable in that script, and fallback to > alternative variant (vi->vim or vim->vi) when the requested editor isn't > available. I would let this be for now - we can combine the idea with env variable if there are any complaints later.
OK, so it looks like I have to follow these instructions: https://docs.pagure.org/copr.copr/how_to_enable_repo.html#how-to-enable-repo Then run this: dnf install vim-wrappers After creating a new terminal, I do now see things like this: [1]- Stopped vim [2]+ Stopped vim ifs.sh So it seems that the problem I reported is fixed by this. Thanks for the hard work fixing it! What should I do with the packages I just installed? Will they be replaced by official packages, and will it then be possible to disable this specific repository?
>> This is probably happening since F32 (F31 runs vi when both are available). > > Hmm, I see the commit introducing this behavior in 2016 (approx Fedora 23). > The commit: I tested under root account only; the thing is that there I'm a little bit more worried about security -- and that there's a potential that vim will parse some broken custom startup script (while vi wouldn't).
> What should I do with the packages I just installed? Will they be replaced by > official packages, and will it then be possible to disable this specific > repository? It depends on the version the official vim will have. But always you can do `dnf copr remove zdohnal/vim && dnf distrosync vim-enhanced`.
(In reply to Paul Boddie from comment #8) > OK, so it looks like I have to follow these instructions: > > https://docs.pagure.org/copr.copr/how_to_enable_repo.html#how-to-enable-repo > > Then run this: > > dnf install vim-wrappers You could cherrypick only the links to rpms and put them into dnf transaction. > > After creating a new terminal, I do now see things like this: > > [1]- Stopped vim > [2]+ Stopped vim ifs.sh > > So it seems that the problem I reported is fixed by this. Thanks for the > hard work fixing it! I'm sorry for taking it so long - there was several issues and the approach I spent most time didn't work and it isn't applicable neither according FPG for this use case. > > What should I do with the packages I just installed? Will they be replaced > by official packages, and will it then be possible to disable this specific > repository? I recommend downgrading/removing the testing packages and removing the repo. The stable packages will hopefully arrive soon, if there will be more issues regarding the change.
FEDORA-2021-28ea6a9932 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-28ea6a9932
FEDORA-2021-ecb1a9ffb0 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2021-ecb1a9ffb0
FEDORA-2021-28ea6a9932 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-28ea6a9932` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-28ea6a9932 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-ecb1a9ffb0 has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-ecb1a9ffb0` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-ecb1a9ffb0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
*** Bug 1925181 has been marked as a duplicate of this bug. ***
(In reply to Zdenek Dohnal from comment #0) [.. breaks sudo .. ] Furthermore, those alias sub-shell shenanigans break zsh job control. (For details see: https://unix.stackexchange.com/q/632989/1131) I really don't understand why it's so important to fall back to vi if the vim command isn't installed. I mean what's the problem with just installing vim if you want to execute vim? Somehow we ended up with wasting everybody's time because some user couldn't be bothered to just type `vi` (or to just install vim!). And with the latest vim package update from testing each time I start vim now a superfluous shell process is started first due to the added wrappers.
FEDORA-2021-28ea6a9932 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Fedora Update System from comment #18) > FEDORA-2021-28ea6a9932 has been pushed to the Fedora 33 stable repository. > If problem still persists, please make note of it in this bug report. I don't find that update in the Fedora 33 repositories. The latest version is 2:8.2.2146-2.fc33
The view wrapper, apparently only intended for use with vim-minimal installed, runs the 'vi' variant without -R. What is the point of this exercise? Just install appropriately-named vi and vim binaries and be done with it. One would think Fedora would have learned this lesson by now, after the whole 'vimx' fiasco.
(In reply to Georg Sauthoff from comment #17) > I really don't understand why it's so important to fall back to vi if the > vim command isn't installed. > > I mean what's the problem with just installing vim if you want to execute > vim? > > This behavior was introduced based on users feedback here https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2DLBCPWOQDDB7MW26NMDBCEMYHQQWA47/#FJIVXUWGEMU4PGC5DTPAAJHPT2X7DOOX and several other following bugzillas. The basic idea is a Vim user just wants to edit text and doesn't care whether he uses vi/vim, because the commands are the same, the final binary is built from the same project and their differences don't matter for simple, quick text editing.
(In reply to Villy Kruse from comment #19) > (In reply to Fedora Update System from comment #18) > > FEDORA-2021-28ea6a9932 has been pushed to the Fedora 33 stable repository. > > If problem still persists, please make note of it in this bug report. > > I don't find that update in the Fedora 33 repositories. The latest version > is 2:8.2.2146-2.fc33 Hi Willy, once the update is shown as a stable in bodhi, there is an interval between 'pushed into stable' and 'being available in stable repositories' - and its length depends on how quick repository mirrors are updated (from my experience, it takes a day or so). AFAIK there is nothing you or I can do to speed up the process, I'm sorry :( .
(In reply to Zdenek Dohnal from comment #22) > (In reply to Villy Kruse from comment #19) > > (In reply to Fedora Update System from comment #18) > > > FEDORA-2021-28ea6a9932 has been pushed to the Fedora 33 stable repository. > > > If problem still persists, please make note of it in this bug report. > > > > I don't find that update in the Fedora 33 repositories. The latest version > > is 2:8.2.2146-2.fc33 > > Hi Willy, > > once the update is shown as a stable in bodhi, there is an interval between > 'pushed into stable' and 'being available in stable repositories' - and its > length depends on how quick repository mirrors are updated (from my > experience, it takes a day or so). > AFAIK there is nothing you or I can do to speed up the process, I'm sorry :( > . I was expecting to find the updates in updates-testing. The new version is now available.
(In reply to Rob Foehl from comment #20) > The view wrapper, apparently only intended for use with vim-minimal > installed, runs the 'vi' variant without -R. > Mayby you meant that the last line of /usr/bin/view should read exec /usr/libexec/vi -R "$@" > What is the point of this exercise? Just install appropriately-named vi and > vim binaries and be done with it. One would think Fedora would have learned > this lesson by now, after the whole 'vimx' fiasco.
Hi Rob, interesting - view was always a symbolic link to pure 'vi', so I don't understand where '-R' was applied, but you're right, 'view' isn't readonly now. I'll fix it.
(In reply to Villy Kruse from comment #23) > > Hi Willy, > > > > once the update is shown as a stable in bodhi, there is an interval between > > 'pushed into stable' and 'being available in stable repositories' - and its > > length depends on how quick repository mirrors are updated (from my > > experience, it takes a day or so). > > AFAIK there is nothing you or I can do to speed up the process, I'm sorry :( > > . > > I was expecting to find the updates in updates-testing. The new version is > now available. Hmm... do you mean the update already wasn't in update-testing and hasn't arrived into stable repos yet? Strange, I haven't hit such a state yet, good to know. (In reply to Villy Kruse from comment #24) > Mayby you meant that the last line of /usr/bin/view should read > > exec /usr/libexec/vi -R "$@" > Applied in the lastest commit. But I don't know where the old versions applied '-R', because they created a symlink to 'vi' as well.
(In reply to Zdenek Dohnal from comment #26) > > Applied in the lastest commit. But I don't know where the old versions > applied '-R', because they created a symlink to 'vi' as well. Some programs tests the name by which it is run. If vi checks argv[0] and find the name "view" it might invoke read-only mode.
(In reply to Villy Kruse from comment #27) > (In reply to Zdenek Dohnal from comment #26) > > > > > Applied in the lastest commit. But I don't know where the old versions > > applied '-R', because they created a symlink to 'vi' as well. > > Some programs tests the name by which it is run. If vi checks argv[0] and > find the name "view" it might invoke read-only mode. See the src/main.c file in the vim sources. /* * Check for: [r][e][g][vi|vim|view][diff][ex[im]] (sort of) * If the executable name starts with "r" we disable shell commands. * If the next character is "e" we run in Easy mode. * If the next character is "g" we run the GUI version. * If the next characters are "view" we start in readonly mode. * If the next characters are "diff" or "vimdiff" we start in diff mode. * If the next characters are "ex" we start in Ex mode. If it's followed * by "im" use improved Ex mode. */ static void parse_command_name(mparm_T *parmp) {
Ah, you're right, I now recall 'Vim' has this feature... that explains that extra 'view' symlink, which I removed, because it looked as duplicate if we have a new wrapper now... Thanks for checking it!
(In reply to Zdenek Dohnal from comment #25) > interesting - view was always a symbolic link to pure 'vi', so I don't > understand where '-R' was applied, but you're right, 'view' isn't readonly > now. I'll fix it. It's implicit if Vim is started with an executable named 'view'. See, for example, ':help view': view vim -R Start in read-only mode (see |-R|). *view* The whole of ':help starting' is worth reading, since these wrappers are causing havoc for anyone taking advantage of the things Vim does already, starting it with combinations of options via custom shell functions / aliases / etc. To reiterate: Please stop shipping wrappers, aliases, system-wide profile scripts, and so on. All of these issues would be resolved by shipping Vim as /usr/bin/vim, and /usr/bin/vi as a symlink in all cases, along with the links for the rest of the applicable names, and adjusting the packages so that the most capable build is the only one left standing: minimal < enhanced < X11. There isn't any good reason for any of the link names to be a different binary, and it's annoying as hell when 'vi' isn't the Vim that knows how to load everything else present. The aforementioned 'vimx' fiasco is also due to Vim not knowing that name: that binary really needs to be called 'vim', with an additional link named 'gvim'. (See also ':help -v'.)
I agree with those questioning this "fix", as well as the previous shell aliases & functions attempt. It is laudable to have wanted to respond to the concerns voiced by a small number of users in that thread that seems to have prompted all this (https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2DLBCPWOQDDB7MW26NMDBCEMYHQQWA47/#FJIVXUWGEMU4PGC5DTPAAJHPT2X7DOOX), but this is such a central, important utility used by an enormous user base and needs more careful consideration when making such fundamental changes. Please keep /usr/bin/vim the actual built binary that so many people expect. I do understand the desire to release a small, stripped down rpm that provides just the traditional vi behavior without all the vim bloat. I also understand the complaint that it is confusing for someone to install a vim rpm ("vim-minimal") but then not be able to type "vim" (ie., that rpm doesn't lay down the vim binary). It seems to me that there are two options (ignoring the misguided wrapper and shell alias/function hacks): (1) Rename the "vim-minimal" rpm to something that might set expectations better that the package isn't providing "vim" (and then don't attempt to support a vim command that isn't the true vim binary). - or - (2) Release the "vim" binary along with the "vim-minimal" rpm.
(In reply to Rob Foehl from comment #30) > It's implicit if Vim is started with an executable named 'view'. See, for > example, ':help view': > > view vim -R Start in read-only mode (see |-R|). *view* > > The whole of ':help starting' is worth reading, since these wrappers are > causing havoc for anyone taking advantage of the things Vim does already, > starting it with combinations of options via custom shell functions / > aliases / etc. Aha, you're right - then I'll make the 'vim -> vi' functionality optional for those, who really wants the functionality. Probably via env variable. EDIT: Setting environment variable doesn't work in sudo... so it behaves there the similar way as an alias, so I don't see a reason for introducing a new variable. The users which want the vim -> vi behavior will set up their own aliases (as it was before :( ). From ex/view//rvim/rgvim... aliases the only 'view' is affected - others still exist as symlinks, but now to /usr/libexec/{vi,vim}, so vim should be able to run them with pre-defined options. The problem are their 'vim <option>' equivalents, which will be run as 'vi' if 'vim' is missing. > > To reiterate: > > Please stop shipping wrappers, aliases, system-wide profile scripts, and so > on. All of these issues would be resolved by shipping Vim as /usr/bin/vim, > and /usr/bin/vi as a symlink in all cases, along with the links for the rest > of the applicable names, and adjusting the packages so that the most capable > build is the only one left standing: minimal < enhanced < X11. There isn't > any good reason for any of the link names to be a different binary, and it's > annoying as hell when 'vi' isn't the Vim that knows how to load everything > else present. > IIUC this would require conflicting among minimal, enhanced and X11, so the only one 'vim' will be installed. IMHO at least vim/gvim must be a different binaries to prevent installation of X11 support, if an user doesn't want to use GUI. The same can be applied to 'minimal'/'enhanced'. (In reply to Glenn Zazulia from comment #31) > I agree with those questioning this "fix", as well as the previous shell > aliases & functions attempt. It is laudable to have wanted to respond to > the concerns voiced by a small number of users in that thread that seems to > have prompted all this > (https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/ > thread/2DLBCPWOQDDB7MW26NMDBCEMYHQQWA47/#FJIVXUWGEMU4PGC5DTPAAJHPT2X7DOOX), > but this is such a central, important utility used by an enormous user base > and needs more careful consideration when making such fundamental changes. I concur - that's why I discuss these decisions on mailing lists, so everyone is able to respond... if I don't see any objections, I'll apply the changes. > Please keep /usr/bin/vim the actual built binary that so many people expect. I will make 'vim -> vi' functionality optional, so 'vim' will cause an error by default if not installed: ''' /usr/bin/vim: line 8: /usr/libexec/vim: No such file or directory ''' Then you can install 'vim' by following: ''' # dnf install vim ''' or (if you follow the error message exactly) ''' # dnf install /usr/libexec/vim ''' Both commands will get you vim-enhanced. > > I do understand the desire to release a small, stripped down rpm that > provides just the traditional vi behavior without all the vim bloat. I also > understand the complaint that it is confusing for someone to install a vim > rpm ("vim-minimal") but then not be able to type "vim" (ie., that rpm > doesn't lay down the vim binary). That's can be one source of confusion, but in my opinion they are used to call 'vim' and the machines (usually containers here) have only vi installed. However, IMO if the command 'vim' gives you: bash: vim: command not found the first thing I do is putting the command into 'dnf install': # dnf install vim which brings the correct vim subpackage. Vice versa with vi. > It seems to me that there are two options > (ignoring the misguided wrapper and shell alias/function hacks): > > (1) Rename the "vim-minimal" rpm to something that might set expectations > better that the package isn't providing "vim" (and then don't attempt to > support a vim command that isn't the true vim binary). Do you have any suggestions? 'vi' is not correct, because it is not the real 'vi', just vim compiled with small set of features. Btw vim-minimal has an explicit Provides: vi, vim-enhanced Provides: vim and vim-X11 Provides: gvim, so if you put the command name into dnf, the correct package will be installed. > - or - > (2) Release the "vim" binary along with the "vim-minimal" rpm. This will result into bigger vim-minimal package, which is not desirable. To sum the desired features up: - minimal, enhanced and x11 exist on the machine without conflicts - minimal contains vi, enhanced vim and x11 gvim - there can be only one 'vim', otherwise the packages will conflict and cannot be installed at the same time - aliases are no-go, doesn't work for sudo and they require shell restart to load - alternatives for setting up link are no-go, doesn't work for immutable Fedoras - scriptlets are no-go, doesn't work for immutable Fedoras by default (they are run on server side by default...) - wanted 'view -> vim -R' if vim is installed and work in sudo - wanted 'vi -> vim' (it is in Fedora for 4 years) if vim is installed and works with sudo - 'vi -> vim' works under root too (decided to support this three months ago, in the same thread mentioned above) - vim pre-defined aliases work as should From the point I see it, the wrappers will be used for vi and view, '/usr/bin/vim' will be a binary, because if the 'vim -> vi' feature is removed, there is no need for 'vim' as a wrapper. IMO It should meet all desired features.
(In reply to Zdenek Dohnal from comment #32) ... > That's can be one source of confusion, but in my opinion they are used to > call 'vim' and the machines (usually containers here) have only vi installed. Yes, I read that complaint, but I don't necessarily agree with it. Just because someone is used to calling "vim" doesn't mean that you should support that for a non-vim rpm. If someone builds/uses a container without vim and then wants to be able to call "vim", then they should either install the proper vim rpm or rebuild the container to include it. Imagine if a container includes only emacs, but users of the container want to be able to call "vim". Surely the fix isn't to adjust the emacs rpm to supply a vim wrapper that can respond to "vim" calls directing a "dnf install" or some other action. If someone argues that the two cases are different because the "vim-minimal" rpm name implies that the package provides "vim", then change the name of the package to something else, as I my last comment offered as option #1. Note that I don't really love this suggestion because dropping "vim" from the name of a binary rpm whose source rpm is vim seems potentially confusing, but maybe it would be less confusing than supplying a vim-named rpm that doesn't supply vim. > However, IMO if the command 'vim' gives you: > > bash: vim: command not found > > the first thing I do is putting the command into 'dnf install': > > # dnf install vim > > which brings the correct vim subpackage. Vice versa with vi. > > > It seems to me that there are two options > > (ignoring the misguided wrapper and shell alias/function hacks): > > > > (1) Rename the "vim-minimal" rpm to something that might set expectations > > better that the package isn't providing "vim" (and then don't attempt to > > support a vim command that isn't the true vim binary). > > Do you have any suggestions? 'vi' is not correct, because it is not the real > 'vi', just vim compiled with small set of features. I hear that but then by the same argument it is not correct for vim-minimal to supply a /usr/bin/vi command since that is not really Bill Joy's traditional vi utility. It's only a vi compatible utility. It seems that Fedora & GNU/Linux decisions over the years have been less purist in nature -- not just with vim supplying a vi command, but with bash supplying /bin/sh (bourne shell). Notice that with the bash rpm, it simply supplies both bash and sh (similar to my previous option #2). > Btw vim-minimal has an explicit Provides: vi, vim-enhanced Provides: vim and > vim-X11 Provides: gvim, so if you put the command name into dnf, the correct > package will be installed. > > > - or - > > (2) Release the "vim" binary along with the "vim-minimal" rpm. > > This will result into bigger vim-minimal package, which is not desirable. > > > To sum the desired features up: > - minimal, enhanced and x11 exist on the machine without conflicts > - minimal contains vi, enhanced vim and x11 gvim > - there can be only one 'vim', otherwise the packages will conflict and > cannot be installed at the same time > - aliases are no-go, doesn't work for sudo and they require shell restart to > load > - alternatives for setting up link are no-go, doesn't work for immutable > Fedoras > - scriptlets are no-go, doesn't work for immutable Fedoras by default (they > are run on server side by default...) > - wanted 'view -> vim -R' if vim is installed and work in sudo > - wanted 'vi -> vim' (it is in Fedora for 4 years) if vim is installed and > works with sudo > - 'vi -> vim' works under root too (decided to support this three months > ago, in the same thread mentioned above) > - vim pre-defined aliases work as should > > From the point I see it, the wrappers will be used for vi and view, > '/usr/bin/vim' will be a binary, because if the 'vim -> vi' feature is > removed, there is no need for 'vim' as a wrapper. IMO It should meet all > desired features. I understand your summary of requirements, but the difficulty results from that construction -- in particular that first one. What if you tweaked them slightly, such as follows: - Relax the requirement that minimal & enhanced must exist simultaneously without conflicts. Why not allow them both to supply conflicting vim, vi, view, ex, etc. For the minimal case the supplied commands are based on the vi-compatible binary, and for the enhanced case the supplied commands are based on the full vim binary. Then one would choose the small package or the large one but not both. - Supply "view" (and "ex", etc.) as a symlink to either vi (in vim-minimal) or vim (in vim-enhanced). You end up with the same result since the utility looks at how it's invoked (Arg 0).
After sending my last suggestion (in comment #33), I realized that I was vague in writing that both minimal & enhanced rpms should supply vim. I didn't mean that vim-minimal should supply a vim that is a link to the reduced vi-compatible binary (which Zdenek had previously argued rightly that it would be confusing to run vim and experience the reduced vi-compatible feature set) but the same fully-functional vim binary supplied by vim-enhanced, without all the /usr/share/vim bloat. The size difference between the vi & vim binaries is only about 2 MB, while the /usr/share/vim files supplied by vim-common adds over 35 MB. Also, to be clear, I don't mean to argue that the only proper solution is to provide vim with vim-minimal. I was perfectly satisfied with the previous approach of installing vim-minimal to get vi functionality and vim-enhanced to get full vim functionality. If you want to entertain the complaints that a vi-compat rpm must supply a vim command, though, then I would argue that simply providing the full vim binary is better than hacking up a vim wrapper script that deviates from vim upstream.
(In reply to Glenn Zazulia from comment #33) > (In reply to Zdenek Dohnal from comment #32) > ... > > That's can be one source of confusion, but in my opinion they are used to > > call 'vim' and the machines (usually containers here) have only vi installed. > > Yes, I read that complaint, but I don't necessarily agree with it. Just > because someone is used to calling "vim" doesn't mean that you should > support that for a non-vim rpm. If someone builds/uses a container without > vim and then wants to be able to call "vim", then they should either install > the proper vim rpm or rebuild the container to include it. Imagine if a > container includes only emacs, but users of the container want to be able to > call "vim". Surely the fix isn't to adjust the emacs rpm to supply a vim > wrapper that can respond to "vim" calls directing a "dnf install" or some > other action. :D funny example, thanks! :D On the serious side, emacs is a different project, and the original argument was 'vi is just vim compiled differently, their difference in features doesn't matter for simple editing, so why bother me if I write 'vim' instead of 'vi', it should work if 'vi' exists'. > > Do you have any suggestions? 'vi' is not correct, because it is not the real > > 'vi', just vim compiled with small set of features. > > I hear that but then by the same argument it is not correct for vim-minimal > to supply a /usr/bin/vi command since that is not really Bill Joy's > traditional vi utility. It's only a vi compatible utility. It seems that > Fedora & GNU/Linux decisions over the years have been less purist in nature > -- not just with vim supplying a vi command, but with bash supplying /bin/sh > (bourne shell). Notice that with the bash rpm, it simply supplies both bash > and sh (similar to my previous option #2). IMO /usr/bin/vi (the new one, compiled from Vim sources) was created to have seamless upgrade from the old Vi, so the other processes don't notice a change. I know it is kind of a shenanigan, but still better than solving upgrades issues and coordinating a system wide change and, again :), coming up with a new name. But IMHO changing an rpm name is more visible change and it should reflect the current origin of the package. > > I understand your summary of requirements, but the difficulty results from > that construction -- in particular that first one. What if you tweaked them > slightly, such as follows: > > - Relax the requirement that minimal & enhanced must exist simultaneously > without conflicts. Why not allow them both to supply conflicting vim, vi, > view, ex, etc. For the minimal case the supplied commands are based on the > vi-compatible binary, and for the enhanced case the supplied commands are > based on the full vim binary. Then one would choose the small package or > the large one but not both. > - Supply "view" (and "ex", etc.) as a symlink to either vi (in vim-minimal) > or vim (in vim-enhanced). You end up with the same result since the utility > looks at how it's invoked (Arg 0). IMHO your suggestions can be done properly only via wrappers :) , I'll explain: 1) currently all three vim version are compiled from a single srpm, meaning it has one SPEC file 2) because of being them in the same srpm, I don't think you can create a symlink, which resides in the same path, but has its target as two different places (view -> vi, view -> vim) 3) the number 2) could be solved by two ways: A) with scriptlets or alternatives, which will set up the correct target during dnf transaction - but neither works in immutable Fedoras such CoreOs or Silverblue B) creating 'vi'/'vim'/'gvim' with the same name - 'vim' 4) the point 3B) has a following downside - though you can ship 'vim' with all subpackages, but it will be the same binary, because it has the same name... so there are again two options: A) ship 'overpowered' 'vim' with all packages, and have different symlinks in specific subpackages - but it contradicts with minimalization, brings up gui deps atd... so no-go B) ship those three version under different names - vi.vim, vim.vim, gvim.vim - and set up the 'vim' link during installation via scriptlets or alternatives - and again, you're in 3B) - those don't work on immutable Fedoras 5) so the next option I can think of is to build those Vim versions in separate RPMs, but: A) IIRC it is against Fedora Packaging Guidelines if vim-minimal and vim-enhanced would share 'view' symlink https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_ownership B) IMHO it is not worth of trouble comparing with pros it will bring :( So in the end, you need something which will be installed as view/ex etc., gives you a seamless switching between vi/vim without any scriptlets or alternatives, which will work with sudo, because it resides in its PATH... wrappers. (In reply to Glenn Zazulia from comment #34) > Also, to be clear, I don't mean to argue that the only proper solution is to > provide vim with vim-minimal. I was perfectly satisfied with the previous > approach of installing vim-minimal to get vi functionality and vim-enhanced > to get full vim functionality. If you want to entertain the complaints that > a vi-compat rpm must supply a vim command, though, then I would argue that > simply providing the full vim binary is better than hacking up a vim wrapper > script that deviates from vim upstream. Ok, I'll sum up the current Vim state I have prepared locally: 1) 'vim' will be a full fledged binary - since 'vim -> vi' functionality is removed (because its optional setup via env variable doesn't work in all cases - does not work with sudo), there is no need for 'vim' being a wrapper. The users who wants the functionality they can setup an alias. 2) 'vi' and 'view' will be wrappers to provide seamless switching between vi and vim if vim-enhanced is installed/removed (vim-minimal must be installed). This will fix the original alias 'alias vi=vim', which will now work without restarting bash, works for root and with sudo.
(In reply to Glenn Zazulia from comment #34) > After sending my last suggestion (in comment #33), I realized that I was > vague in writing that both minimal & enhanced rpms should supply vim. I > didn't mean that vim-minimal should supply a vim that is a link to the > reduced vi-compatible binary (which Zdenek had previously argued rightly > that it would be confusing to run vim and experience the reduced > vi-compatible feature set) but the same fully-functional vim binary supplied > by vim-enhanced, without all the /usr/share/vim bloat. The size difference > between the vi & vim binaries is only about 2 MB, while the /usr/share/vim > files supplied by vim-common adds over 35 MB. > Notice: vim-minimal does not require vim-common
FEDORA-2021-e083708650 has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-e083708650` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-e083708650 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-e083708650 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.