[1/2] gnu: Add allegro.

  * gnu/packages/game-development.scm (allegro): New variable.
---
 gnu/packages/game-development.scm | 41 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)
  

On Tue, Jul 19, 2016 at 4:57 PM, Ricardo Wurmus <rekado@elephly.net> wrote:
> * gnu/packages/game-development.scm (allegro): New variable.
> ---
>  gnu/packages/game-development.scm | 41 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
>
> diff --git a/gnu/packages/game-development.scm b/gnu/packages/game-development.scm
> index b11285a..03623aa 100644
> --- a/gnu/packages/game-development.scm
> +++ b/gnu/packages/game-development.scm
> @@ -7,6 +7,7 @@
>  ;;; Copyright © 2015, 2016 David Thompson <davet@gnu.org>
>  ;;; Copyright © 2016 Efraim Flashner <efraim@flashner.co.il>
>  ;;; Copyright © 2016 Kei Kebreau <kei@openmailbox.org>
> +;;; Copyright © 2016 Ricardo Wurmus <rekado@elephly.net>
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -342,6 +343,46 @@ etc.")
>      (home-page "http://liballeg.org")
>      (license license:giftware)))
>
> +(define-public allegro

Shouldn't this be allegro-5 since there is already an allegro-4?

Other than that it looks good to me.

- Dave
  

Thompson, David <dthompson2@worcester.edu> writes:

> On Tue, Jul 19, 2016 at 4:57 PM, Ricardo Wurmus <rekado@elephly.net> wrote:
>> * gnu/packages/game-development.scm (allegro): New variable.
>> ---
>>  gnu/packages/game-development.scm | 41 +++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 41 insertions(+)
>>
>> diff --git a/gnu/packages/game-development.scm b/gnu/packages/game-development.scm
>> index b11285a..03623aa 100644
>> --- a/gnu/packages/game-development.scm
>> +++ b/gnu/packages/game-development.scm
>> @@ -7,6 +7,7 @@
>>  ;;; Copyright © 2015, 2016 David Thompson <davet@gnu.org>
>>  ;;; Copyright © 2016 Efraim Flashner <efraim@flashner.co.il>
>>  ;;; Copyright © 2016 Kei Kebreau <kei@openmailbox.org>
>> +;;; Copyright © 2016 Ricardo Wurmus <rekado@elephly.net>
>>  ;;;
>>  ;;; This file is part of GNU Guix.
>>  ;;;
>> @@ -342,6 +343,46 @@ etc.")
>>      (home-page "http://liballeg.org")
>>      (license license:giftware)))
>>
>> +(define-public allegro
>
> 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”.

~~ Ricardo
  

> > 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.
  

On Wed, Jul 27, 2016 at 05:54:31PM +0200, Danny Milosavljevic wrote:
> 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").
> If something becomes incompatible, its name should change.

It is our common practice to not re-encode the version into the name: Usually
the unnumbered name simply stands for the latest version, Only when we need to
keep several versions around do we add a versioned name for the earlier one.
In this way, updating dependencies becomes easier: Most of the time, a later
version of a dependency will work. To follow your suggestion, we would
ultimately add the soname of libraries to package names, and then whenever
some package is updated, all packages depending on it would need to have
their inputs rewritten. This would not be very practical.

Andreas
  

Hi Andreas,

On Wed, 27 Jul 2016 18:19:18 +0200
Andreas Enge <andreas@enge.fr> wrote:

>It is our common practice to not re-encode the version into the name: Usually the unnumbered name simply stands for the latest version

That's unfortunate. I can live with it - but there is a reason the API major versions are usually encoded there. Otherwise it's not possible to ever make a clean API break and be safe with it.

Just to make sure: I'm not saying the API major number should absolutely be part of the name, I'm saying there should be version bounds for all the inputs of packages.

> In this way, updating dependencies becomes easier: Most of the time, a later version of a dependency will work. 

Then there would have been no reason to update the API major number in the first place. Of course I can think of scenarios where it would work regardless - for example if the package used only a subset of the entire functionality, it could be that this subset is still compatible.

Python 3 is an example - few Python 2 programs will work on Python 3 without changes - so it makes no sense to "autoupdate" a Python 2 package to a Python 3 interpreter in isolation. Of course, if you are lucky, you can find some subset where it happens to work by accident.

When Python 4 is released, a similar argument can be made.

>To follow your suggestion, we would ultimately add the soname of libraries to package names, 

Only the part that is the API (in)compatibility version number - but yes.

> and then whenever some package is updated, all packages depending on it would need to have
> their inputs rewritten. 

Hopefully after checking whether the new API actually still does the right thing for it...

Thanks, good to know the common practice.
  

Hello,

just replying to part of your message, since I think there might be a
misunderstanding:

On Wed, Jul 27, 2016 at 11:06:15PM +0200, Danny Milosavljevic wrote:
> Just to make sure: I'm not saying the API major number should absolutely be part of the name, I'm saying there should be version bounds for all the inputs of packages.

The inputs of our packages are absolutely precise: They are given as scheme
variables (which are, in a sense, a moving target, since their content
changes over time; but they are completely fixed at any given point in time).
So we have no way of saying, like in many other distributions, that the input
is any "python >= 2 and < 3"; in fact, we are always saying "use exactly
this Python, with this source, build system, inputs, etc.".

If a package x has as input "python", this is the scheme variable of this name,
which, in my current git tree, refers to a package containing Python 3.4.3,
and nothing else. Another package y may have as input "python-2", which is a
scheme variable containing currently Python 2.7.10. In core-updates, we
updated python-2 to contain Python 2.7.11. So the input to package y,
compiled in core-updates, is still called "python-2", but has actually
changed. The variable names are just conventions; and it is almost a pure
coincidence that they usually are the same as the "name" field of the
package record :-)

But maybe I simply misunderstood your comment. Anyway, upgrading has been
working generally well so far. Also, it is not always easy to determine
whether APIs are compatible or not, since they are not necessarily tied
to major versions of the software. For instance, I think that anything
(or almost) written for gmp-4 still compiles with gmp-5 or 6. But this
requires some familiarity with the code, which I have in this case since
I am following the gmp development. Apart from that, we have thousands of
packages now, some of which are probably not familiar to anybody. I know
that I packaged software of which I did not even understand the description,
just because it was a prerequisite for something I am interested in...

Andreas
  

Andreas Enge <andreas@enge.fr> writes:

> The inputs of our packages are absolutely precise: They are given as scheme
> variables (which are, in a sense, a moving target, since their content
> changes over time; but they are completely fixed at any given point in time).
> So we have no way of saying, like in many other distributions, that the input
> is any "python >= 2 and < 3"; in fact, we are always saying "use exactly
> this Python, with this source, build system, inputs, etc.".

For this reason, the exact structure of the name doesn't seem too
important.  My understanding is that Nix and Guix both avoid "nominal"
dependency specifications specifically it's unreliable.  The first few
pages of Eelco Dolstra's Nix thesis [1] discuss the pitfalls of
"nominal" dependency specification:

"Related to the inability to validate dependency specifications is the
fact that dependencies tend to be inexact. Above, xhello required that a
component named hello is present — but it makes no requirements on the
actual properties or interfaces of that component. That is, the
dependency specification is nominal (determined by name only), not by
contract (requiring that the dependency has certain properties). So any
component named hello satisfies the dependency. Actually, we can require
specific versions of the dependency:

    Requires: hello >= 1.0

which excludes version 1.0. However, such version specifications involve
a high degree of wishful thinking, since we can never in general rely on
the fact that any version in an open range works. For instance, there is
no way to know whether future release 1.3.1 of hello will be backwards
compatible. Even “exact” dependencies such as

    Require: hello = 1.0

are unsafe, because this is still a nominal dependency: we can conceive
of any number of component instances with name hello and version number
1.0 that behave completely differently. In fact, this is a real problem:
Linux distributions from different vendors can easily have components
with equal names (e.g., glibc-2.3.5) that actually have vendor-specific
patches applied, have been built with specific options, compilers, or
ABI options, and so on."

[1] https://nixos.org/%7Eeelco/pubs/phd-thesis.pdf