On Tue, 30 Mar 2021, Matěj Cepl wrote:

Dne 30. 03. 21 v 14:50 Filip Kadlec napsal(a):

...

This is perhaps a simple omission to include a newer version into the distro, or may this be an intention...?

Anyway, I would like to point at this obsolete package, hoping the latest version can be included into the distribution update.

https://youtu.be/mxa4HDgfWFs

“Ask not what your country can do for you - ask what you can do for your country, …” Nice. This is exactly what I am trying to do. I have already spent quite some time tracing this bug and trying to figure out where the problem is. However, as a simple user, I know nothing of who decides about including or not the latest packages updates.

https://en.opensuse.org/Portal:Factory

(however, in terms of vim plugins … I more and more believe that actually distribution packages are not the best way how to consume vim plugins, just install them in your ~/.vim directory from the upstream directly)

Sure, I could do this; uninstall the distro-plugin, and use my version. In this way, I would not care about possible bugs in the distribution. It would mean less work for me and no benefit to the community. But I am not giving up yet.

Best,

Matěj

Hi, Simon, if I am able to help with this, yes, I am willing to learn that and participate. I know the current plugin version is at GitHub, so I would need someone to explain me how to update the files in the repository. Filip On Wed, 31 Mar 2021, Simon Lees wrote:

For a large number of the smaller packages it basically comes down to if someone cares enough about the package to update it then it will get updated, if no one cares enough it probably wont.

Updating a package like this is generally pretty straight forward and an ideal task for a first time contributor so if you would like to become the person who cares enough to make sure the package gets updated there are plenty of people here who would be more then willing to help you get started.

Hello, Am Donnerstag, 1. April 2021, 22:38:31 CEST schrieb Matěj Cepl:

Dne 30. 03. 21 v 16:44 Filip Kadlec napsal(a):

...

Sure, I could do this; uninstall the distro-plugin, and use my version. In this way, I would not care about possible bugs in the distribution. It would mean less work for me and no benefit to the community. But I am not giving up yet.

I think it is necessary to consider what is the purpose of distributions and what *value* they add. We can add a lot of value by integrating various C packages (or other complicated ones; I am maintainer of Python packages),

Packaging python modules sounds superfluous, people could just use pip install *SCNR*

but what value we bring for vim plugins? We just make situation more complicated for users when reporting their issues to make path towards upstream developers more complicated and mostly routine repackaging just makes time for updates longer.

You could argue this way for basically everything - whatever the distribution ships puts a MitM between the user and upstream, sometimes delays the update because the packager is busy with other stuff, and maybe makes local updates more complicated. However, that's the point of having a distribution - provide everything[tm] as packages so that the average user doesn't have to care about updates etc. Yes, this sometimes means shipping older software than available upstream, but I happily pay that price if it saves me from having to manage my vim plugins, python modules, ... myself. Fun fact: actually I have a few vim plugins installed locally. I installed them years ago and never updated them, so please don't argue with getting newer upstream versions faster ;-) So, long story short - please continue to package vim plugins. Also, whenever someone asks "does packaging $whatever make sense?", just answer "yes" unless you have a very good reason for a different answer. Regards, Christian Boltz -- That's the theory. And in theory, there is no difference between theory and practice, right? [Martin Wilck in opensuse-factory]

Hello,

 I want just to remind that the issue of the obsolete package is still not resolved. I will happily assist with that if someone indicates me how to proceed.

 Filip

On Fri, 2 Apr 2021, Christian Boltz wrote:

...

Hello,

Am Donnerstag, 1. April 2021, 22:38:31 CEST schrieb Matěj Cepl:

...

Dne 30. 03. 21 v 16:44 Filip Kadlec napsal(a):

...

Sure, I could do this; uninstall the distro-plugin, and use my version. In this way, I would not care about possible bugs in the distribution. It would mean less work for me and no benefit to the community. But I am not giving up yet.

I think it is necessary to consider what is the purpose of distributions and what *value* they add. We can add a lot of value by integrating various C packages (or other complicated ones; I am maintainer of Python packages),

Packaging python modules sounds superfluous, people could just use pip install   *SCNR*

Depends on what you run, how you run. It's certainly not useful to

...

...

but what value we bring for vim plugins? We just make situation more complicated for users when reporting their issues to make path towards upstream developers more complicated and mostly routine repackaging just makes time for updates longer.

You could argue this way for basically everything - whatever the distribution ships puts a MitM between the user and upstream, sometimes delays the update because the packager is busy with other stuff, and maybe makes local updates more complicated.

However, that's the point of having a distribution - provide everything[tm] as packages so that the average user doesn't have to care about updates etc.

Yes, this sometimes means shipping older software than available upstream, but I happily pay that price if it saves me from having to manage my vim plugins, python modules, ... myself.

YMMV. If your selection of email client plugins (hypthetical case) matches what a distribution would deliver, OK. If you can mix&match without breaking stuff, also OK. If you are restricted to the bundled

Am 08.04.21 um 10:36 schrieb Filip Kadlec: package "everything" like we did back in the CPAN days. If you want to provide some tools as a distribution which happen to be built in python, ruby, php... you can either distribute static builds (phar, composer trees, pip environments) or package libraries for re-user/de-duplication. The former is not very distribution-ey, the latter can give you lots of headaches with version requirement clashes which are not always easy to mend. The value of the (FOSS) distribution would be to have a consistent access to some tool set (installers, for example) or applications (db, desktop, ...) which do not require you to setup nat to the internet or multiple specific repositories (npm, composer/satis, a pip mirror, a cpan mirror ...) The added value of a commercial distribution would be support promises independent of upstream's planned or unplanned discontinuation, architecture decision etc. That's critical if your platform/language has BC breaking changes and has discontinued support for the older major version, but your software product on top needs to stay on some older version (maybe because of critical plugins not yet available). Now there's user groups which are not very interested in these guarantees or have other priorities. There have always been people who deployed (or even locally compiled) their own builds or nightly releases of web servers, databases, scripting languages...  to consume latest features or fixes or because they needed buildtime configurations a distribution would not ship. Docker/containers changed that game a lot. However, while I am a user and advocate of openSUSE based docker images, most standard distributions of mainstream software like apache, nginx, mariadb, ruby are based on something else.  plugins because the vendor's app store has been patched out, maybe not so funny. I would not want to micromanage vim plugins or latex modules or applications for the emacs OS. On the other hand, I see no way any distribution could service me a relevant part of the thunderbird, chromium, vscode plugin ecosystems in a sane and completely satisfying way.

...

Fun fact: actually I have a few vim plugins installed locally. I installed them years ago and never updated them, so please don't argue with getting newer upstream versions faster ;-)

So, long story short - please continue to package vim plugins. Also, whenever someone asks "does packaging $whatever make sense?", just answer "yes" unless you have a very good reason for a different answer.

Yes, that's part of why should I choose distribution X. Does it deliver the thing I need to work with or do I need to curl around for some blobs or installers from some vendors and cross fingers that it won't dislike my distribution's default file system (minikube) or just segfault or assume certain libraries to be in some hardcoded path. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Hello, Am Donnerstag, 8. April 2021, 17:08:27 CEST schrieb Matěj Cepl:

Dne 02. 04. 21 v 13:37 Christian Boltz napsal(a):

...

You could argue this way for basically everything - whatever the distribution ships puts a MitM between the user and upstream, sometimes delays the update because the packager is busy with other stuff, and maybe makes local updates more complicated.

No, I cannot, and you don't seem to read what I wrote. For complex packages (Python- or whateverelse- based) we provide unbundling, automatic updates (including updates of unbundled libraries), fixing integration issues, a lot of things.

What value we bring for a vim plugin?

* no unbundling (in 99% case there is nothing to unbundle) * no integration issues (I don't know how or even if we deal with vim/neovim distinction, and that's the only possible issue which comes to my mind)

Maybe I should have added a "devil's advocate" note to my previous mail, and also to this mail ;-) No worries, I know that there are differences on the amount of work that packaging saves users etc., and that packaging of base libraries can be seen as more important than packaging of simple plugins ("more important" as in "amount of saved work for users", and I also know that average users probably undervalue the work spent on packaging base libraries because they are "just there" and only get noticed if they are missing). Nevertheless, having simple [to install] things packaged also makes users' live easier, therefore I see no reason to stop packaging them.

* slower updates (whichever method of vim package management you use, it is faster than waiting on openSUSE packages)

I disagree ;-) - but it of course it depends on how you manage your vim plugins. My method for vim plugins is "download the plugin once, and only look at it again if/when it breaks" (hey, I'm lazy ;-) which means some of my plugins are quite old. I just had a look - several of them are from 2004, and I have a surprisingly low number of files in ~/.vim with a 201x or 202x date. Therefore I slightly ;-) doubt that distribution-packaged plugins would be older. Of course, that's just _my_ ~/.vim/ ;-) and while I use vim a lot, I see it more as a tool that "just has to work" and don't want to maintain that tool myself unless I really have to.

* slower access to the issue resolution

For bugs I didn't even notice, yes. But then, if I didn't notice the breakage, I probably don't need a quick fix ;-) For bugs I reported myself, I know how to apply the fix locally (and/or do a SR to the package). (That applies to everything, not only to vim plugins.)

Older software? vim-plugin-fugitive in Factory is from 2019-10-11! I have latest update of fugitive (with fixes I've negotiated with upstream recently) from 34 hours ago.

See above - your mileage obviously varies ;-)

...

Also, whenever someone asks "does packaging $whatever make sense?", just answer "yes" unless you have a very good reason for a different answer. I agree, but for vim plugins there are plenty of very good reasons for a different answer. See above.

You have good reasons to manage your vim plugins without rpm. Fine. You can even install plugins in ~/.vim that override those in /usr/share/vim/, so you can easily have newer versions than packaged. But let me ask the other way round: Does any of the RPMs cause problems or conflicts with your way of managing vim plugins? If not, I still think packaging them is a good idea to make it easier for whoever prefers the easy way ;-) Regards, Christian Boltz --

I like science when some "vodoo" is needed to make it work ;-) Magic is just another word for indistinguishable advanced technology :D [> Bruno Friedmann and Jan Engelhardt in opensuse-factory]