Ludovic Courtès <l...@gnu.org> writes: > Ben Sturmfels <b...@sturm.com.au> skribis: > >> So I think the bug is that the user interface could be more helpful here. >> It should probably either tell you what happened and what you can do to >> fix it, or offer to resolve the conflict/perform the upgrade for you. > > Would it be desirable or even feasible to resolve the conflict for you? > I wouldn’t want the tool to remove installed packages without asking me, > for instance.
Guix could resolve the conflict by upgrading the existing and conflicting item in the profile. In my experience that’s usually what a user wants. Guix could also remind the users to use “--manifest” or to upgrade items in the profile. > Could you suggest messages you’d like to see in this case? In this case it is not entirely clear that the existing python-requests package in the profile is “old”. The version looks the same and the hash is opaque. Would it be possible to record something about the Guix version that was used to install a package? Then we could say: An older variant of python-requests is installed in this profile (propagated from package “foo-bar”) and conflicts with a newer variant (propagated from package “python-twine”). I understand that it is challenging to accurately describe the version of Guix in the presence of GUIX_PACKAGE_PATH. With a more formal definition of channels (e.g. requiring a description file for the channel that includes a version or date string) this problem could be side-stepped. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
