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