Hi Phil,
On Thu, 20 Oct 2022 at 22:37, Phil <p...@beadling.co.uk> wrote:
> A change in a package ("dependency" in the below example) in a channel I
> own has caused a conflict in another package in the same channel that depends
> on it ("test-package" in the below). Whilst fixing the "test-package"
> package is the right solution, this is too complicated in do in the
> short-term. I need to pin "dependency" to v1.0 in test-pacakge's
> propagated-inputs. Simultaneously, other packages need the new update to
> the "dependency" package to use this functionality to deliver new
> functionality that can't wait.
>
> This isn't a one-off situation; this happens frequently and I'm
> interested in how other Guixers resolve this with as little friction to
> users as possible?
Well, I answer to this question and I do not answer to your question
about inferior…
> One brainwave I had was to use inferiors - but this doesn't seem to
> work. Continuing from the above example we could define access to a
> historical v1.0 of the dependency package for the test-package like so:
>
> (define dependency-inferior
> ;; An inferior containing dependency v1.0.
> (inferior-for-channels dependency-channels))
…instead of defining a complete inferior, why not just define 2
packages. Something as,
(define-public foo
(package
(name "foo")
(version "2.0")
[...]
(define-public foo-1.6
(package
(inherit foo)
(name "foo")
(version "1.6")
[...]
For an example, see python-numpy and python-numpy-next in (gnu packages
python-xyz).
Note that most CLI as “guix install foo” will install the last version.
Hence the ’-next’ trick in the package name. :-) Depending what you
would like to be the “default“.
Cheers,
simon
