Upgraded Jail to 12.2 and then upgraded pkgs. Now gvim is gone.

byrnejb

byrnejb

I have a jail that I have previously used gvim on:
Code: 
history | grep gvim
. . .
 3141  2021-04-09 08:52:18: gvim master/192.168.8.public.rev
 3208  2021-06-03 12:05:13: gvim signtest/harte-lyne.ca.hosts
 3271  2021-09-28 14:09:21: gvim signtest/harte-lyne.ca.hosts
 3286  2021-09-28 15:22:53: gvim signtest/harte-lyne.ca.hosts
. . .

Last week I upgraded first the jail to 12.2p10. Then I logged on and upgraded the pkgs:
Code: 
# hg upgrade
. . .
 3305  2021-10-14 11:58:09: pkg upgrade
 3307  2021-10-14 11:58:48: pkg upgrade -f pkg
 3312  2021-10-14 12:00:20: pkg upgrade

Today, I logged on to that jail and tried to run gvim:
Code: 
# gvim
bash: gvim: command not found

There is no /usr/local/bin/gvim to /usr/local/bin/vim softlink.

So, I created it:
Code: 
# ln -s /usr/local/bin/vim /usr/local/bin/gvim
# which gvim
/usr/local/bin/gvim
# gvim
E25: GUI cannot be used: Not enabled at compile time

If I do a package search for gvim nothing show up.

I have another system also at 12.2p10. Like the system above it has vim-8.2 installed, albeit vim-8.2.3081/CMD] rather than [CMD]vim-8.2.3458/CMD]. However, it has [CMD]gvim and it works.

What is going on? Is this some sort of bug? Is a pkg upgrade supposed to break things like this?
 
On the off chance that this was a packaging change I installed vim-x11, which likewise is not compiled with the GUI enabled:
Code: 
# pkg install vim-x11
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
    vim-x11: 8.2.3458

Number of packages to be installed: 1

The process will require 34 MiB more space.
7 MiB to be downloaded.

Proceed with this action? [y/N]: y
[dns38.harte-lyne.ca] [1/1] Fetching vim-x11-8.2.3458.pkg:  47%    4 MiB   3.7MB/s    [dns38.harte-lyne.ca] [1/1] Fetching vim-x11-8.2.3458.pkg: 100%    7 MiB   7.8MB/s    00:01    
Checking integrity... done (1 conflicting)
  - vim-x11-8.2.3458 conflicts with vim-8.2.3458 on /usr/local/bin/evim
Checking integrity... done (0 conflicting)
Conflicts with the existing packages have been found.
One more solver iteration is needed to resolve them.
The following 2 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
    vim: 8.2.3458

New packages to be INSTALLED:
    vim-x11: 8.2.3458

Number of packages to be removed: 1
Number of packages to be installed: 1

Proceed with this action? [y/N]: y
[dns38.harte-lyne.ca] [1/2] Deinstalling vim-8.2.3458...
[dns38.harte-lyne.ca] [1/2] Deleting files for vim-8.2.3458: 100%
[dns38.harte-lyne.ca] [2/2] Installing vim-x11-8.2.3458...
[dns38.harte-lyne.ca] [2/2] Extracting vim-x11-8.2.3458: 100%
[root@dns38 ~ (master)]# gvim
E25: GUI cannot be used: Not enabled at compile time
 
editors/vim was changed a while back. It now defaults to console only. If you want the GTK2 or 3 version, install the flavor; pkg install vim-gtk2 for example.

Code: 
root@pibsd:~ # pkg search vim-
py38-pynvim-0.4.3              Python client and plugin host for Neovim
py38-vim-bridge-0.6            Decorator enabing transparent calls to Python functions in Vim scripts
vim-8.2.3458                   Improved version of the vi editor (console flavor)
vim-athena-8.2.3458            Improved version of the vi editor (athena flavor)
vim-gtk2-8.2.3458              Improved version of the vi editor (gtk2 flavor)
vim-gtk3-8.2.3458              Improved version of the vi editor (gtk3 flavor)
vim-motif-8.2.3458             Improved version of the vi editor (motif flavor)
vim-tiny-8.2.3458              Improved version of the vi editor (tiny flavor)
vim-x11-8.2.3458               Improved version of the vi editor (x11 flavor)

ports - FreeBSD ports tree

cgit.freebsd.org cgit.freebsd.org
 
I reverted to vim-8.2.3081 which solves the missing gvim problem for now. I have opened a bug report as well.
 
SirDice said:
editors/vim was changed a while back. It now defaults to console only. If you want the GTK2 or 3 version, install the flavor; pkg install vim-gtk2 for example.
Click to expand...
And people wonder why many admins put off doing regular upgrades. Nothing like have shifting sands under your feet to give you that feeling of confidence. J.H.C.

As I recall, there existed a vim-console package. What was wrong with that?
 
byrnejb said:
I have opened a bug report as well.
Click to expand...
It's not a bug. Ports change all the time. Learn to deal with that.

byrnejb said:
And people wonder why many admins put off doing regular upgrades.
Click to expand...
All admins I know have zero issues with upgrades. It's part of their job. It comes with the territory.

byrnejb said:
As I recall, there existed a vim-console package. What was wrong with that?
Click to expand...
Ask the maintainer of the port.
 
I suppose that, since the editor window opened, this is nothing to worry about. But it is disconcerting.
Code: 
# pkg install vim-gtk2
# gvim

  backupdir=~/.vim/tmp
** (gvim:31328): CRITICAL **: 11:26:56.615: murrine_style_draw_box: assertion 'height >= -1' failed
 
And no-one you know has ever had a problem with a system or software upgrade from a vendor? None? Ever? And you yourself have never experienced an upgrade go south in 25 years? Ever? Really?

I myself have not had such luck.

.
 
byrnejb said:
And no-one you know has ever had a problem with a system or software upgrade from a vendor? None? Ever?
Click to expand...
Problems, sure. But nothing that couldn't be resolved by actually looking into the issue. In almost all of the times it was because we or I did something wrong. The other times we worked with the vendor(s) to get things resolved. And we actually test updates or upgrades. So by the time we get to touch production systems we are well aware of the caveats.

byrnejb said:
And you yourself have never experienced an upgrade go south in 25 years? Ever? Really?
Click to expand...
I've had one upgrade go south, yes. That one resulted in a completely hosed and unrecoverable system. But that was because I didn't read the instructions, I made the mistake that screwed everything up.
 
Of course software updates can cause problems but depending on time and resources there's a reasonable amount that can be done to prepare for an unforeseen event.

Even FreeBSD 13 changed the MOTD handling and that was undocumented IIRC. Was it a problem for me, yes - I needed to alter a deploy script I'd written for a particular use case. Was it a problem for most people, no.

byrnejb, SirDice spends so much time posting in these forums I often doubt he has a job at all.
 
You must log in or register to reply here.
Back
Top