Re: Stratification of GNU Guix into Independent Channels

[Giovanni Biscuolo]

Hi,

just a quick comment

zimoun <zimon.toutoune@gmail.com> writes:

[...]

> Moreover, many channels would be dependant from one to the other.

and this would be **a nightmare** to maintain (as already clearly stated
by others much more competent than me in Guix-things)

to recap: all PROS that you jgart mentioned in his original message does
not apply (or are "reversed" to CONS) and users would not benefit of
this kind of modularity in terms of speed (likely speed would be much
worse with more than 4 channels to pull in, and 4 channels would be too
few for a complete system)

as far as I can understand from my journey in Guix, it has the **great**
advantage to /expose/ the weaknesses of some (some?) upstream packages
not so... diligent with dependency hygiene, leading to the **big**
problem of dependency hell or dependency confusion, that sooner or later
/someone/ (distro mainatienrs often) have to solve *before* including
that package in the distribution (unlike what is happening with PyPI,
npm and alike: good luck users!)

as Liliana said:

--8<---------------cut here---------------start------------->8---

 What does work is convincing upstreams to pull in less dependencies and
 drop the outdated ones, because that makes it so that eventually Guix
 has to ship less packages.

--8<---------------cut here---------------end--------------->8---

Unfortunately I have the impression that not so many upstream developers
are really aware of the problem and when they are they think it's a
problem of someone else, not their.

Minimalism at (Guix) System level, one package at a time.

Happy hacking! Gio'

[...]

P.S.: the elevator pitch of all this thread could be: «yes, software
systems are way too /complicated/... but please don't blame Guix for it
(instead "git blame" and bless it!)» :-D

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

signature.asc
Description: PGP signature