devel/allegro-devel: Update to 5.2.4.0 and take MAINTAINER'ship

[rainbow_purlinux.org]

Summary

This port appears to have been abandoned by the current maintainer
and efforts to contact them have been unsuccessful.

This change updates the port to 5.2.4.0 (the latest release) and
updates MAINTAINER to myself

Reviewed_by: ???
Approved by: ???
Differential_Revision: D15504

Test Plan

• portlint:
• testport: (poudriere: <versions>, <archs>[, <options> tested)
• maketest: (if test target exists)

[rainbow_purlinux.org]

Whoops. Still more used to git than SVN I'm afraid.
Caught the accidental deletion of the deluge-cli patch.

[rainbow_purlinux.org]

Resetting my svn tree to remove that, and updating the diff

[rainbow_purlinux.org]

Fixing error from diff submission

[rainbow_purlinux.org]

This diff *actually* fixes my mistake from earlier. Sorry about that, y'all!

[koobs]

If Allegro 5 is a 'stable' 'release', then the main allegro port (devel/allegro, currently unmaintained) should be updated to this version, with this port (devel/allegro-devel) updated to a development versions, or deleted if there are none, or is no longer needed.

devel/allegro-devel/Makefile

6

When PORTVERSION/DISTVERSION is updated, PORTREVISION should be reset (removed)

29

GH_TAGNAME defaults to PORTVERSION (or DISTVERSION) by default. It can be removed.

[rainbow_purlinux.org]

In D15504#327257, @koobs wrote:

If Allegro 5 is a 'stable' 'release', then the main allegro port (devel/allegro, currently unmaintained) should be updated to this version, with this port (devel/allegro-devel) updated to a development versions, or deleted if there are none, or is no longer needed.

Allegro 4x is still loosely maintained. It may be beneficial to move devel/allegro to devel/allegro4, and change devel/allegro-devel to devel/allegro, as Allegro 5 is the current stable branch, and there is no current development branch (which would be Allegro 6 when they get there)
I think that would be the best move.
I've never been part of a port change like that though, and would definitely appreciate feedback or guidance on that. I assume that would involve:

1. Create devel/allegro4 port
2. Move the proposed changes here to devel/allegro
3. Delete devel/allegro-devel port

[koobs]

In D15504#327262, @rainbow_purlinux.org wrote:

In D15504#327257, @koobs wrote:

If Allegro 5 is a 'stable' 'release', then the main allegro port (devel/allegro, currently unmaintained) should be updated to this version, with this port (devel/allegro-devel) updated to a development versions, or deleted if there are none, or is no longer needed.

Allegro 4x is still loosely maintained. It may be beneficial to move devel/allegro to devel/allegro4, and change devel/allegro-devel to devel/allegro, as Allegro 5 is the current stable branch, and there is no current development branch (which would be Allegro 6 when they get there)
I think that would be the best move.
I've never been part of a port change like that though, and would definitely appreciate feedback or guidance on that. I assume that would involve:

1. Create devel/allegro4 port
2. Move the proposed changes here to devel/allegro
3. Delete devel/allegro-devel port

There's a few paths (described as a target state)

1. devel/allegro4 and devel/allegro5 ports, delete - "two stable release branch ports"
2. devel/allegro (5.x) and devel/allegro4 (4.x) - "update main, fork port for previous branch"
3. devel/allegro (4.x) and new devel/allegro5 (5.x) - "current port stays as is, new port for new version"

Things to consider (not in any order):

• maintenance overhead
• how long each upstream major branch is supported for (long time, short time)
  • Are the defined EoL's known for each known in advance?
  • Are they close?
• how many concurrently supported table releases are there at any one time (in general, in the future)
• the upgrade path of each of the above
• the upgrade path complexity/risks/user experience for users, specifically re going through a major version (path (2) above)

[rainbow_purlinux.org]

I haven't abandoned this, just a heads up!
Been very busy with work.
I'll respond in depth soon so we can get something working here :)

[tcberner]

devel/allegro-devel/Makefile

19

^ LIB_DEPENDS=

26

^ use tabs after =, not spaces.

68

ALSA_CMAKE_BOOL=WANT_ALSA

71

^ also CMAKE_BOOL

[rainbow_purlinux.org]

@tcberner Thanks for that :)
I didn't write the original Makefile and my initial goal was to simply get it up to date, before delving in and making sure everything else was bueno.
I'm still rather new to porting and maintaining Ports Makefiles.

@koobs

There's a few paths (described as a target state)

devel/allegro4 and devel/allegro5 ports, delete - "two stable release branch ports"
devel/allegro (5.x) and devel/allegro4 (4.x) - "update main, fork port for previous branch"
devel/allegro (4.x) and new devel/allegro5 (5.x) - "current port stays as is, new port for new version"

It appears that Allegro 4 is no longer maintained, however I'm getting confirmation in IRC.

Edit Confirmation Acquired
<rmbeer> hackerhorse, allegro4 is no longer maintained, it only serves for old machines...

I think the ideal path to take, however, is to change devel/allegro to devel/allegro4 for backwards compatibility,
and create a new devel/allegro5 port. This way, when Allegro 6 comes around and 5 is still maintained, we can
provide a similarly named port for version 5 without worrying about accidentally messing up someone's games.

Things to consider (not in any order):
maintenance overhead

Doesn't seem like much

how long each upstream major branch is supported for (long time, short time)

It appears that they stay on a single major version for years

Are the defined EoL's known for each known in advance?

I can't find any record of communication on this but I'll get clarification

Are they close?

Unknown at this time

how many concurrently supported table releases are there at any one time (in general, in the future)

Stable releases? It appears there are a few, but within the same major branch, however I do not believe it will hurt us to simply track latest
per major version. That appears to be recommended.

the upgrade path of each of the above

Seems like a simple rebuild and install, they don't appear to have any wonky build or upgrade requirements

the upgrade path complexity/risks/user experience for users, specifically re going through a major version (path (2) above)

As the library itself is used by games, and it's up to the game developer to specify which version they're using,
the target path i described above should make this a null issue

[mat]

devel/allegro-devel/Makefile

9

Set this to ${DISTNAME}${EXTRACT_SUFX}. Otherwise, it is wrong.

11

This should be ${DISTNAME}${EXTRACT_SUFX} too.

44

You could remove 5.0.10 from here, it is old and the port version is more recent.

55–56

USES=uniquefiles:dirs

64

Wrong place in the Makefile. See Chapter 15. Order of Variables in Port Makefiles.

[rainbow_purlinux.org]

I didn't abandon this submission. just a heads up. I've been stupid busy with work and finally have some weekends again. I'll get back to this next Saturday and make the suggested updates.