Hi Russ,
see below.
Best Regards,
Jürgen
On 6/28/24 05:46, Russtopia wrote:
Hi, I have a few questions about the versioning and distribution of
GNU APL as it stands today:
1. Versioning
GNU APL is apparently still officially '1.8'. Even after many, many
bug fixes and enhancements, since the last official .tar.gz archive on
the main GNU APL packages pages at https://ftp.gnu.org/gnu/apl/ (dated
2019-06-23). What would constitute a v1.8.1, or v1.9? Is the SVN
revision to be considered the de-facto 'build step' eg. v1.8.1775M?
In the early days I was committing bug fixes directly into the
https://www.gnu.org/software/apl,
stepping up the revision number with each commit. Shortly after I got
complaints from the GNU
project the my commit frequency was too high because they could not
synchronize their servers
that fast.
At that point I decided to build full new releases only occasionally and
distribute changes via subversion.
Building a new release is more work that committing changes; it is
supported by scripts but still takes a
day pr two because problems are typically reported just after every release.
I was a little lazy in the last year. Maybe I should create an GNU APL
1,9 although the would not fix the
underlying problem that the official release will always be behind the
most recent version.
2. git mirror commit comments lack any version and SVN revision info
git is only a secondary source and the commits are created
automatically. I am working with different subversions,
a local one with frequent commits and the one on savannah with fewer
commits. This makes it impossible to have
a single revision suffix that increments linearly.
However, the revision number in the savannah repo should do it for
downstream distributions.
The official git repo mirroring svn has rather un-informative git
commit comments, each one saying only "sync from SVN"; the output of
`svnversion`, if nothing else, would be more useful as a git comment
so that those using the git mirror would at least know what SVN
version each commit represents, as discussions on this bug list seem
to almost exclusively refer to the SVN version as the canonical
identifier.
3. Availability of (more) up-to-date versions for downstream packaging
systems
Currently, according to the GNU APL site at
(https://www.gnu.org/software/apl/), to obtain a version of GNU APL
more recent than the rather old one posted at
https://www.gnu.org/software/apl/ (dated 2019-06-23) one is directed
to either use SVN or the git repo which is synchronized with it directly.
Actually Debian had plans to include GNU APL and I was hoping that they
come back to me to discuss versioning.
But apparently the priority is too low:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949948;msg=2
I'm trying to submit an update to the Funtoo Linux project to add GNU
APL as a package in their 'ebuild' system. ebuild uses an 'autogen'
tool with 'generators' which are canned methods of fetching from a few
common types of web resources: currently github, gitlab (via their
unique release- or tag-based APIs), or generic HTML directory listings
of versioned tar.gz archives, such as the release directories
published by GNU at the link in point 1. above.
Funtoo doesn't currently appear to have a 'generator' for either
direct SVN checkouts or git clones, so the two obvious ways to get a
recent GNU APL source distribution are both inaccessible to its
package manager.
That seems to be a major limitation of Funtoo and not of GNU APL. I
would assume that if
they are able to update from github then they should be able to update
from the savannah git repository as well.
I'm trying to work with them to add a 'generator' that can fetch svn
or git upstream repos directly, but if that fails, is there a
particular reason why we could not or would not have periodic postings
of newer tarballs to the GNU mirrors?
Every local build creates, among other things, an up-to-date tarball. As
a matter of fact, the savannah svn and git
repos are unpacked tarballs (see targets DIST: and SYNC: in the
top-level Makefile.am. So the tarball and the svn and git repose
are just different representations of the same thing. The repos are
extracered tarballs and the tarballs can be restored with
*make dist* in the checked-out repos.
Perhaps there are reasons why this isn't being done already, but I
believe it would help promote the popularity and visibility of GNU APL
if new releases were made available to Linux distros by making more
recent release tarballs available.
I'm willing to do the work on the package manager side for the Linux
distros I use (Debian/Devuan and Funtoo), but it would be easier if
there were 'official' up to date .tgz files for package manager tools
to download :)
Thanks,
-Russ
