Hi, thanks for the informative answer. It does seem strange that they don't make an easy way to just access the svn or git repo directly when it's not part of github or gitlab.
I did not think about the `make dist`, thanks for pointing that out. So that would solve how to get a current tarball; I did have a solution whereby I just self-host the tarball on a web space I control, but I think Funtoo wants a source on some 'official' host... For now I will see if the Funtoo people are able to point me to another way, or if I can learn how to add a suitable 'generator' to their fetch system for svn or plain git. -Russ On Fri, Jun 28, 2024 at 4:08 AM Dr. Jürgen Sauermann < mail@jürgen-sauermann.de> wrote: > 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 > > >
