[Top][All Lists]

[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 

If something becomes incompatible, its name should change.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]