Hello,
I have been using Tumbleweed for several years now, convinced that
"Any user who wishes to have the newest packages that include, but are not limited to, the Linux kernel, ... and many other packages, will want Tumbleweed." (from https://build.opensuse.org/project/show/openSUSE:Factory )
It seems, however, that the vim-plugin-latex package included in the distribution (as well as in Leap) is quite outdated: Yast reports 20120125-39.6, so more than nine years old (?) although the Change Log in Yast shows some later changes, the newest being the line:
Mon 11 Nov 2019 13:00:00 CET Johannes Thumshirn jthumshirn@suse.com - Update vim-plugin-fugitive to upstream version 3.1
In fact, some features introduced 6 years appear to be missing in the package within the distribution, namely the Python support,
https://github.com/vim-latex/vim-latex/blame/master/ftplugin/latex-suite/mai...
Consequently, the plugin implements wrongly some important functionality, such as multiple compilation (see, e.g., ":help compiling-multiple" within vim or gvim).
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.
Best regards,
Filip
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.
“Ask not what your country can do for you - ask what you can do for your country, …”
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)
Best,
Matěj
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.
“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
On 3/31/21 1:14 AM, Filip Kadlec wrote:
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.
“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.
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.
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.
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), 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.
Best,
Matěj
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
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*
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
Am 08.04.21 um 10:36 schrieb Filip Kadlec:
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 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.
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 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.
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) * slower updates (whichever method of vim package management you use, it is faster than waiting on openSUSE packages) * slower access to the issue resolution
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.
From 79 vim plugins I have installed, you have only four and even those are completely obsolete.
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.
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.
Best,
Matěj
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
Dne 08. 04. 21 v 22:56 Christian Boltz napsal(a):
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.
OK, I don’t know how to reply to this politely. “I behave [unwisely] and openSUSE doesn’t pretend to do something about it.”
There seem to be two alternatives:
* tell you to behave [wisely] (to say it nicely) and let you live with consequences of your actions, * pretend that we do something for you even though we don’t (see https://build.opensuse.org/package/show/openSUSE:Factory/vim-plugins )
I strongly vote for removing this package from Factory and not lying to our users that we support them, when we don’t. Apparently, most users already gave up on our non-packaging and they use standard vim tools.
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 ;-)
Point of the package updates is that you are continually getting fixes for all bugs collected by all users of the software. With our vim-plugins you don’t.
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 ;-)
Just we are not honest with our users, when we pretend (by providing the packages) to support when we actually don't do anything. And the answer is not “so, just update vim-plugins package”, because then we get to my previous analysis, why our packaging is The Wrong Thing™ to do.
Best,
Matěj
Hi Filip,
On Tue, Mar 30, 2021 at 3:00 PM Filip Kadlec kadlecf@fzu.cz wrote:
Hello,
I have been using Tumbleweed for several years now, convinced that
"Any user who wishes to have the newest packages that include, but are not limited to, the Linux kernel, ... and many other packages, will want Tumbleweed." (from https://build.opensuse.org/project/show/openSUSE:Factory )
It seems, however, that the vim-plugin-latex package included in the distribution (as well as in Leap) is quite outdated: Yast reports 20120125-39.6, so more than nine years old (?) although the Change Log in Yast shows some later changes, the newest being the line:
Mon 11 Nov 2019 13:00:00 CET Johannes Thumshirn jthumshirn@suse.com - Update vim-plugin-fugitive to upstream version 3.1
In fact, some features introduced 6 years appear to be missing in the package within the distribution, namely the Python support,
https://github.com/vim-latex/vim-latex/blame/master/ftplugin/latex-suite/mai...
Consequently, the plugin implements wrongly some important functionality, such as multiple compilation (see, e.g., ":help compiling-multiple" within vim or gvim).
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.
We always update when we can, but looks like vim-plugins is horribly outdated anyway. Maybe it'd make sense to create a standalone vim-latex package conflict with vim-plugins. Eventually, maybe we could drop vim-plugins completely.
Regards, ismail
Best regards, Filip
On 30. 03. 21, 14:50, Filip Kadlec wrote:
It seems, however, that the vim-plugin-latex package included in the distribution (as well as in Leap) is quite outdated: Yast reports 20120125-39.6, so more than nine years old (?)
Provided vim is my daily bread, I found some spare time, so: https://build.opensuse.org/request/show/884559
More updates may come (or you are free to add more or update the rest similarly).
P.S. and no, I don't want to install and manage vim plugins manually on my 10+ machines for every single user on them. Which is in par with Christian's opinion in this thread.
-
Christian Boltz -
Filip Kadlec -
İsmail Dönmez -
Jiri Slaby -
Matěj Cepl -
Ralf Lang -
Simon Lees