Re: Channel dependencies

[ludo@gnu.org (Ludovic Courtès)]

Hello!

Chris Marusich <cmmarusich@gmail.com> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Good point.  I agree that it’s similar to the question of propagated
>> inputs, which we deal with by reporting an error when a collision
>> arises.
>>
>> So, similarly, I think the safe way would be to report an error when
>> channel requirements conflict.
>
> With profiles, two packages conflict if and only if a file exists at the
> same relative path in both packages' outputs.

What you describe here are “soft collisions”, which the profile builder
reports as warnings (which are invisible with today’s ‘guix package’.)

I was referring to profile collisions where two packages with the same
name end up in the same profile (the ‘&profile-collision-error’
exception.)

This exception would also be raised if ‘guix pull’ ended up adding the
same channels more than once in ~/.config/guix/current.

> Also like you said, we can try to implement some heuristics to reject
> situations in which a "channel conflict" is likely.  Would it be hard to
> change the channel mechanism so that it fails if there are any (normal)
> conflicts while generating the profile that contains all the channels?
> If we could prevent those (normal) conflicts while generating the
> profile, it would prevent a certain class of channel conflicts: namely,
> it would be impossible for two channels to provide the same guile
> modules.

‘union-build’ has a #:resolve-collision parameter.  We could set it when
building ~/.config/guix/current so that an error is raised when the same
file is provided more than once.

(It’s a simple change we can make independently of what Ricardo is
proposing.)

WDYT?

>> We must define what it means for two <channel>s to conflict:
>>
>>   • if a channel’s ‘commit’ is #f, then any channel with the same name
>>     but a different ‘uri’ and/or a different ‘branch’ and/or a non-#f
>>     commit conflicts;
>>
>>   • if a channel’s ‘commit’ is not #f, then any channel with the same
>>     name and otherwise different fields conflicts.
>
> This seems like a reasonable heuristic.  What will we do when two
> channels differ only in their name?  What about when two channels only
> have identical fields?  Maybe in those cases we should just pick one,
> ignore the other, and log a warning, since their content will be the
> same.

Yes, they would effectively be ‘equal?’.

>> If we have inspiration later, we can liberalize this, for instance by
>> using several inferiors.  It would be quite a bit of extra work, and
>> it’s not immediately clear to me how that could work.  I believe what
>> Ricardo proposes already covers many use cases anyway.
>
> You're probably right.  I'm just trying to think about how we might
> apply the functional model to this problem, rather than implementing
> heuristics.  But maybe heuristics are good enough!

Sure, and that’s good!

Thanks,
Ludo’.