On 16.05.21 22:35, Alexis PM via Dng wrote:

Hi,

> Standardize the package format of the released versions of each free
> software project would be a total and desirable revolution.

Note that I'm *no way* proposing some standardized package format,
especially NOT for binary distribution/deployment.

We just could introduce some standardized *source* metadata that covers
the most common things (eg. standard build systems like automake, cmake,
etc, description of simple daemons, ...). But some "universal package
format" is deemed to fail.

> The burden of offering the available software would shift to software
> developers rather than distributions.

Absolutely NOT. They're are the totally wrong parties for doing that.
We've seen that over decades, when upstreams (especially commercial
ones) publish binary packages for some hand picked distros. It just
doesn't work. They don't, and they practically can't, care of all the
specialities of distros - which DO have their justification. The success
of FOSS (especially GNU/Linux) comes exactly from the huge diversity of
the dozens distros that all have their own scope and audience.

A communist equilibrium that some folks (eg. the Lennartists) would be
killing this prolific diversity of distros. We need clear borders
between the realms of upstreams and distros as well as an vivid
collaboration between them.

> Your "oss-qm" (it would be good to indicate the URL of the project)

What's left of it can be found on github:
https://github.com/oss-qm

> has not been the only initiative to create a standard of released software
> package for the software developers that allows to surpasses the diversity
> of packages formats.

No, that never has been the goal of oss-qm. It does NOT attempt any
unification of actual package formats. Just a pool for collecting fixes
and cleanups onto upstream releases, so individual distros don't need to
carry huge patch queues and heavily package specific build instructions
anymore.

> A big problem is that many free software developers hardly take the time to
> publicly offer the code of their software organized according to their personal
> way of organizing the code without testing in the complex diversity of the
> universe beyond their computer (they know that their software runs fine in
> their operating system and development environment that is distro X version
> Y with versions of the dependencies A.B.C, D.E.F., G.H.I.), > leaving the distros the role of compiling and packaging the software and
> dealing with what errors arise in architectures and combinations of versions
> of dependencies that are different from the software developer's computers.

This isn't so hard to solve, when upstreams and distro maintainers
closely work together, use CIs (that automatically build/deploy/test on
many distros).

One vital point missing in most of the upstreams: stable maintenance
branches, where bugfixes (eg. coming from distros) quickly move in.
Other is general awareness of the needs of distros (eg. customizability,
standardized build systems, etc)

> As a note of the difficulty of standardizing the content of the packages of
> released versions by the developers, even something that should be as simple
> as clearly indicating in a file the licenses of all the software contained
> in the package, is something that is usually done wrong.

Right. Part of the problem is that many packages are just too huge and
should be splitted into several smaller ones. And the worst problems of
all is "vendoring" - bundling 3rdparty code into some package.


--mtx

--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@??? -- +49-151-27565287