[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Package API compatibility and guix package variable names
From: |
Danny Milosavljevic |
Subject: |
Package API compatibility and guix package variable names |
Date: |
Wed, 27 Jul 2016 17:54:31 +0200 |
> > Shouldn't this be allegro-5 since there is already an allegro-4?
>
> I want the “allegro” variable to simply hold the latest version of
> allegro. If ever there’s a need to clarify (e.g. because we need to
> keep around the last of the 5.x series when 6.x comes out) we can change
> the name then. As far as I can see that’s been our approach for some
> other packages, too, most prominently “python”.
In my humble opinion it would best if there was an "allego-5.0" and an
"allegro" variable, with the "allegro" variable not being referenced by any
other package (they would reference "allegro-5.0" instead - or whatever major
API version they need, for example "allegro-5.2").
This way we wouldn't have to update half of all package specs after they break
just because a new incompatible version came out.
I think the way it was done for Python3 in Guix is wrong. On the other hand,
the way it was done for Python2 in Guix was exactly right.
What happens when a new (incompatible) Python4 comes out? Patch all the Python
modules package specs there are? The only reason we can get away with it for
Python is because they only do breaking change in the language every five years.
This is something Debian got right - have the (API) version as suffix as part
of the name.
The "allegro" metapackage is purely a user convenience (of questionable
benefit).
If something becomes incompatible, its name should change.