Hello, Ricardo Wurmus <rek...@elephly.net> skribis:
>>> * gnu/packages/base.scm (make-glibc-locales, make-glibc-utf8-locales): New >>> procedures. >>> (glibc-locales): Express in terms of make-glibc-locales. >>> (glibc-utf8-locales): Express in terms of make-glibc-utf8-locales. >>> (glibc-locales-2.27, glibc-utf8-locales-2.27): New variables. > > […] > >> I don’t like the package name trick, but I don’t have a better solution. >> Perhaps we could have a special property to explicitly allow for several >> versions of this package in the same profile (say >> ‘allow-multiple-versions?’), but that’s a bit more work. > > I also don’t like to work around this by changing the package names. I > thought of allowing multiple versions via property, but it’s not clear > how it should behave. I’d want to have only major versions appear as > non-conflicting and still prevent the installation of variants of the > same version. > > The next question then is if the property should be a procedure that > takes the current and the potentially conflicting package as arguments > and decides whether they are conflicting, or if this should be handled > centrally when the property is present. Would there be other use cases? If not, I would not worry too much about the major vs. non-major conflicts. I have a slight preference for a property that we can ‘write’, which would simplify for instance interaction with inferior packages, hence something like a Boolean ‘allow-multiple-versions?’ property. As a first approach, when this flag is true, the version check in ‘check-for-collisions’ could be bypassed. The property would have to be added to the <manifest-entry> though, so that the flag is honored even after several “guix package” invocations. How does that sound? Thanks, Ludo’.
