help-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What about dependency resolution à la apt?


From: Tobias Geerinckx-Rice
Subject: Re: What about dependency resolution à la apt?
Date: Thu, 16 Mar 2017 23:45:03 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

Amirouche,

On 16/03/17 21:56, Amirouche wrote:
> Le 16/03/2017 à 21:28, Tobias Geerinckx-Rice a écrit :
>> [...] I'm mainly curious and slightly puzzled as to why
>> this question keeps popping up.
> 
> Sorry!

Not at all. Thanks for making me think about this some more and put my
thoughts into words.

You're the poor sod who has to read them.

>> I hope others will join in, since I fear
>> this hints at some fundamental misunderstandings about Guix that might
>> hurt world d^W^W adoption.
> 
> Maybe patch the FAQ?

I don't even grok the question! :-)

Nor did I know that Guix had a FAQ. Also, the rest of this e-mail should
illustrate why I am not the person to concisely and clearly answer anything.

>> It takes some getting used to when you're used to old-school package
>> managers where the resolver is A Big Deal, or even The Biggest Deal:
>> Gentoo, anyone?
> 
> Yes.. But autoconf does the same, it specify some dependency
> that can match patch or minor version number.

...yyyes. That is true? But...?

I'm afraid I still can't see how this relates to Guix.

Build systems like autotools and package managers like apt and npm hail
from a hostile and fragile world: in general, packages are installed
into a single, shared root filesystem, from constantly updating global
repository.

Oh, and you can hardly ever install more than one version of a package
at a time. And some packages flatly refuse to coexist with others.

In this world, dependencies do indeed need to be ‘resolved’: “Yo, apt,
go fetch a libfoo from the pile that's at least this new (but not part
of the 2.x series!) without breaking these 463 other packages.”

The[1] correct solution may involve up- or downgrading many other
packages, or even removing conflicting ones. All nicely taken care of by
the package manager. Until it breaks. I call it ‘Ubuntu’.

In Guix, installing one package doesn't touch any other package. There
are no conflicts. Package specifications aren't secretly queries with 0
or more matches like in apt, but unambiguous identifiers.

Guix doesn't play fetch. It can't. You tell it exactly which package to
use — and that's a feature.

Perhaps this is where the confusion arises: ‘exactly which packages’
does not mean ‘libfoo == 1.4’. It means ‘this store entry containing
exactly this build of libfoo.’ Maybe it is libfoo 1.4. Maybe it's
patched to hell. It doesn't even matter: the resulting system either
works, or it doesn't.

Phew. Sorry. I warned you.

>> Guix already does ‘equal to’ better than anyone. Bit-identical, even.
> 
> That's is off topic?

Not at all. When you suggest ‘dependency resolution’, you have to think
carefully about what that means and how it would affect this key property.

Anyway, I'll leave the floor to others now.

Kind regards,

T G-R

[1]: ‘A’. This stuff is insanely non-deterministic.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]