Re: Channel dependencies

[Chris Marusich <cmmarusich@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3896 bytes --]

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.  In other words, both
packages provide "the same" file.

With channels, we build a profile containing the union of the channels.
So, normal profile conflicts will definitely occur in the profile if two
channels provide the same module (e.g., $out/my/awesome/packages.scm),
right?  Because we're putting the two channels into a single profile, I
think the normal conflict resolution mechanism will force us to use only
one module in the resulting profile.  And I think that if two channels
provide the same module, it's definitely a conflict of some kind.

Furthermore, if two channels both provide "the same" package definition
for a tool called my-awesome-program in two different modules, Guile
scheme code can still specify precisely which my-awesome-program should
be used.  In that sense, there is no conflict.  However, if both package
definition use the same name and version, then a command like "guix
package -i my-awesome-program" (and the APIs that convert package
specifications to packages) will have to choose one specific package,
right?  In that sense, there is a conflict.

It seems to me that these kinds of conflicts are what we want to avoid.
Regardless of what the channel is named, regardless of what URI it comes
from, regardless of what commit it came from, if it provides the same
modules or the same packages as another channel, there's a "channel
conflict".

However, detecting that sort of conflict seems pretty complicated.  I
don't have a good idea for how to detect it.  It seems like you would
have to traverse the entire set of modules and packages that a channel
provides, and cross-check it with other channels to make sure there are
no conflicts.  We might have to use multiple inferiors to do that, like
you mentioned.

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.

> 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.

> 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!

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]