GAP 4.16.0-beta1

[fingolfin]

Dear all,

I plan to release GAP 4.16.0 in mid-May, assuming all goes well. To prepare for that, I've made a prerelease to allow testing.

Version 4.16.0-beta1 is mostly intended for use by people who package GAP for Linux distributions, or similar things (Homebrew, FreeBSD ports, Conda, SageMath, ...). The idea is to iron out issues related to packaging before the final release.

That said, everyone else is of course also welcome to give it a try. I don't expect major changes in the final release, though we'll still merge PRs and package updates if they don't appear "risky".

You can find this pre-release at https://github.com/gap-system/gap/releases/tag/v4.16.0-beta1

If you want all GAP sources and all packages, you need gap-4.16.0-beta1.tar.gz.

Some people who I know package GAP and might be interested in this include @antonio-rojas @isuruf @saraedum @jamesjer @orlitzky @collares @AndreasEnge @yurivict @kiwifb @mkoeppe

[fingolfin]

See also #6351 for concrete planned steps (more may soon be added), and also the 4.16.0 milestone

[orlitzky]

Nothing too surprising, does kernel_major_version get a bump in configure.ac?

[fingolfin]

Thanks @orlitzky that's an excellent point -- so far, no public kernel APIs changed and I would hence keep kernel_major_version as is.

However, if we merge PR #6376 before the release, then it will have to change.

[mkoeppe]

Update of passagemath to use GAP 4.16.0-beta1 in passagemath/passagemath#2376; binary wheels were built without problem. Tests (including all GAP package testsuites) running at https://github.com/passagemath/passagemath/actions/runs/25474620810/job/74745386794

[fingolfin]

Unfortunately the GAP 4.16.0 release is a bit delayed. But I'd like to get it out by the end of May / first week of June. I thought about just release it today, but figured it would be better to cut a beta2 release instead. A bunch of changes compared to beta1, the most meaningful for packagers probably is that the kernel / libgap version increased.

You can find this pre-release at https://github.com/gap-system/gap/releases/tag/v4.16.0-beta2

I realize that planning to release next week doesn't give much time for testing, but I am prepared to quickly follow up with a 4.16.1 release if necessary.

[fingolfin]

Just to say, if nothing goes wrong, the final release should be very close to beta2. The only change I have planned right now is adding the release notes. Though of course if there are reports about regressions compared to beta1, I'll try to address them.

[orlitzky]

I am also fond of the changes allowing the tests to (mostly) work with --bare, thanks.

[frankluebeck]

I noticed that the v4.16.0-beta2 archive contains many files with strange or inconsistent permissions. In particular there are world writable directories and files in the corefreesub and francy packages.

I suggest to fix and unify permissions by calling

chmod -R -c g-w,o-w,g+r,o+r .

within the GAP root before packing the archive.
I'm doing this anyway in my rsync based GAP distribution, but it would be better to fix this for all users of the archive.

[fingolfin]

@frankluebeck when you say "many files with strange or inconsistent permissions", what do you have in mind besides the two concrete examples you gave?

In general I am wary about changing the package permissions, because e.g. the atlasrep package deliberately wants some writeable directories in its package directory (see also #5190)

[orlitzky]

Stepping out of my lane a bit... for the traditional unpack-and-run install, I think Frank is right. I believe everyone wants the equivalent of tar -xf when unpacking, not tar -xpf. The former extracts as "you," and then applies umask. The latter additionally sets the permissions to whatever they are in the archive.

• tar -xf leaves everything writable by the user who extracted it, so there should be no problem with packages like atlasrep. If I use tar -xf to extract gap in my home directory, then gap (running as my user) can write to ~/gap/pkg/atlasrep.
• tar -xpf can grant owner/group permissions on your files to users who aren't you and aren't in your group
• tar -xpf can leave files world-writable

The last one is particularly bad: if I extract the archive to $HOME with tar -xpf, then francy and corefreesub wind up with source code that is world-writable. Anyone on the machine can edit the source, and the next time I load one of those packages, my account is compromised.

You could try to document this in the install instructions, but I'm sure there are GUI tools that helpfully preserve the permissions by default, and most people aren't going to read and understand the docs. OTOH by fudging the permissions inside the archive, you can help ensure that nothing too bad happens even if the archive is extracted preserving permissions.