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]