Neovim broke, OpenSUSE culture and expectations

Hi all,

I need either some help or some explanation of what I can expect in terms of stability from OpenSUSE Tumbleweed. Let me first describe what happened:

This morning I ran a distribution upgade in myrlyn. It told me some lua dependency of neovim 0.11.4 was going to be deleted, and hence I could choose to either break neovim or delete it too. I figured, don’t want to break my system already since it’s new, so I chose to delete both neovim and the lua dependency and figure out how to restore neovim later. Now neovim is gone, as expected, and installing it again obviously doesn’t help: the lua dependency still isn’t there, as the neovim that’s available is still 0.11.4.

I know tumbleweed is a rolling release distro, which means things might change when you do a major update. But what happened today feels strange: my neovim was uninstalled, and there seems to be no replacement. I used manjaro for a year or two, and that actually felt very stable, even though there were updates all the time. There, my “major” applications never disappeared. So my questions here are as follows:

  1. In OpenSUSE tumbleweed, can I expect “major” applications to remain stably available? Or should I expect to regularly work around temporary missing dependencies, while the maintainers of various packages try to stabilize the dependency hierarchy again? I understand the nature of daily updates, but this time I feel like I really got the rug pulled out from under me; I don’t mind if small specific packages break every once in a while, but I always felt like neovim is not some highly niche program, so it feels weird for maintainers to not notice it’s in a broken state.
  2. It seems Neovim 0.11.5 is available somewhere in the opensuse universe: https://build.opensuse.org/package/show/openSUSE%3AFactory/neovim. My myrlyn still only allows installing 0.11.4. Is 0.11.5 only available for an even more bleeding edge version of opensuse, will it be available to me in a few hours to, or did I just look up some Ubuntu PPA-equivalent for opensuse? What’s going on?
  3. What kind of maintenance should I regularly do with opensuse? Currently I only start myrlyn every once in a while; are there any other apps or news feeds I should check regularly?

Any other mentions of OpenSUSE sites, tech or culture that you think I should read are also welcome. E.g. a while ago I read a post about yast and that was very informative to know where the ecosystem is at currently. I’m new here and eager to learn!

1 Like

It will be available in one of the future Tumbleweed snapshots when it is released. If you desperately need it now you may try to install it from Factory, but it may have dependencies not yet included in the current Tumbleweed snapshot.

This was self inflicted wound:

But yes, you can expect something like this to happen every time you update Tumbleweed. It is up to you to decide whether Tumbleweed is suitable for you.

Nothing. It is absolutely normal in Tumbleweed.

2 Likes

lua51-lpeg is still available in the history repo: here
Download, install manually and lock. Then you should be able to reinstall neovim.
Ask if you need more detail.

And, BTW, welcome to the openSUSE Forums!

@arvidjaar:

you may try to install it from Factory

Okay, so the Factory area is the staging area where the next tumbleweed release is prepared, if I understand correctly.

you can expect something like this to happen every time you update Tumbleweed

What I don’t understand is why the maintainers would delete a package that leaves dependents broken. I would expect that either they would then delete the neovim package too, as in it’s current state it’s useless, or they would leave the lua dependency around for now until the next neovim package is fixed such that doesn’t need it.

I guess the only option of the maintainers of the neovim package is to somehow include the lua dependency, which is missing in the neovim package, directly in the neovim package ? Because I assume the lua package was deleted for a reason, so waiting for it to come back also feels weird…

I guess I don’t mind my package being gone, but I don’t understand the user/maintainer dynamic that’s going on here. If all your packages are constantly under threat of having their dependencies deleted… Or did neovim/lua51-lpeg have this long coming? Is there something like an announcement list of packages that will soon be deleted?

@OrsoBruno:

Download, install manually and lock. Then you should be able to reinstall neovim.

Thanks, it’s nice to know there is a “final” workaround in case I’m on a deadline or something. For now I’m using the appimage to see if maybe the situation resolves itself.

Is this manually downloading and locking process a frequent occurrence of tumbleweed users? What if lua51-lpeg gets added back into opensuse tumbleweed later on? Will you get a nice error message about conflicting dependencies, or will myrlyn just overwrite the local dependency, and leave the system in a weird state?

Sorry for all the questions, I’m used to being coddled by Linux Mint…

It won‘t get added back. Perform a package search via Myrlyn or zypper. You will see that newer versions are already available. Simply perform a search for lua5. You will find lua53-lpeg.

The neovim maintainers needed to rebuild their package to use the new lua versions.
lua53 is available since 2020.

Something like this happens sometimes. Tumbleweed is quite stable but needs some manual intervention from time to time. Some basic linux knowlege is helpful in such cases.

1 Like

I see, I think I understand the situation now. Thanks!

The maintainer is update the package in factory and it is building.
After passing of the QA the packages is going to Tumbleweed and if you install it, it will delete the old package.

And some packages depends on the old package which will also be deleted anbd new package is not build because there are problems on building them on factory ore something else.

This is an automatism.

And this will be often the cause in Tumbleweed.

1 Like

Because as of today there are over 16000 (source) packages in Factory. If every such change will wait until all dependent packages are fixed, there will be virtually no way forward. Before Tumbleweed snapshot is released there are build tests for the core subset of packages (which is one of reasons why there is delay between checking in sources in Factory and releasing binary as part of Tumbleweed). But let’s face it - while neovim may be the major application for you, it is pretty leaf package that most users may not even have heard of. In this case it relies on the respective maintainers being notified about build failures and taking the corrective actions. Which happened really fast in this case (three days ago lua51-lpeg was marked for auto-removal, yesterday neovim was modifed to not require it on Tumbleweed).

If this were rpm I am pretty sure such change would not be released until rpm were fixed.

And it is not that zypper silently removed your major application. It warned you and asked you what to do. It was your decision. The normal course of action in this case is either simply wait until it is resolved or to ask here before taking destructive actions.

2 Likes

No, most such cases are fixed in a week or so, so when such errors arise for a package deemed “critical” by an user, that user often waits a few days for a fix before a system upgrade is done.

You had a nice warning about a conflict and you chose to uninstall neovim: zypper (myrlin is just an interface to libzypp) never leaves a system in a weird state, but user actions can do that at times.
(Well, it might happen, but that would be considered a bug worth reporting…)

3 Likes

You were unfortunate enough to stir a hornets’ nest with this particular TW update.

What apparently happened was that you got a package dependency problem between neovim and lua. This by itself happens on a rolling distribution like Tumbleweed; maybe one of the involved packages (or their other dependencies) didn’t build in Factory.

The problem is that those things tend to cascade; the root of the problem may easily be a few layers deeper between packages that you don’t see immediately involved. What you see in that situation is only the topmost layer.

The dependency resolver (or “solver” for short) tries to find a solution automatically, but if that doesn’t work, it offers you a number of solutions to manually choose from, and that includes some of the more “nuclear” solutions:

  • undo the change that led to the problem (don’t upgrade package X)
  • delete a number of packages (which might be a lot of them, wrecking your system)
  • ignore the problem and break a package (because you might know that you don’t use it anyway)

Sometimes there might be one or two more options.

The solutions range from moderately bad to catastrophic; if there were a good one, the solver would already have chosen it. Typically, the least bad situation is to undo the change; not to upgrade or to install a package that you just manually selected. In other cases, you can choose to remove one or several packages that are all entangled in this dependency mess. But often enough you’ll find yourself removing whole subsystems like all of X11 or all of Wayland, or “just” all of GNOME.

When you are selecting packages manually one by one for installation, upgrade, or removal, it’s easy to identify the “undo” operation in the solutions that the solver offers. But if it hides in a distribution upgrade like here, it might be difficult since the solver tries to do many package upgrades as good as possible, and there will be a lot of changes.

In that situation it’s often best to abort the whole thing (hit Cancel in Myrlyn) and start over, this time maybe with setting some packages that you definitely want to keep untouched to “Protected” (the “locked” equivalent). Or ask in the forum before you do anything drastic. Or simply wait a day or two.

All this shouldn’t happen, but it’s hard to impossible to test every possible combination of packages that users out there might have on their system before deciding which of all the updated packages in Factory go to the next Tumbleweed snapshot, and which don’t.


Since you wrote that you are new to openSUSE (welcome BTW!), maybe Slowroll is a better choice for you: It’s the slower rolling version of Tumbleweed. Tumbleweed is bleeding edge, but sometimes painful things happen. Slowroll leaves the bleeding to the absolutely adventurous users; you can expect problems to be already fixed before they reach Slowroll.

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.