Hello! Chris Marusich <cmmarus...@gmail.com> skribis:
> l...@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’.
