I'd say morsmortium has no real point, it just seems that he doesn't
exactly get how -git packages are supposed to work and how people using
them should keep their software up to date if they so wish.
A -git package should mostly just be a version agnostic build script
that gets the latest code from the upstream source and builds it, which
means its version should not be tied to the software version other than
if there are breaking changes that require the build script to be
adjusted. This means that if you want to update software installed
through a -git package you just rebuild the package with the same PKGBUILD.
It seems that the package maintainer here is just constantly pushing
no-op version bumps to force certain AUR helper behavior instead of just
using an AUR helper correctly, for example yay's --devel option checks
whether or not VCS packages have modifications upstream rather than
relying on the PKGBUILD version.
The reason this can be problematic is that for example when I use
sway-git and wlroots-git, I only explicitly rebuild the software to the
newest version on git if I see something interesting that I want to try
out. It would be weird if someone was bumping the version to try to
bypass the default behavior of the AUR helper I use to try and get me to
update the software when I don't want to, in fact I'd probably think a
no-op update would be someone trying to push out a malicious upstream
update to as many people as possible.
Regards,
Atte
On 9/27/26 2:24 PM, Andreas Reichel wrote:
On Sun, 2026-09-27 at 13:15 +0200, Ralf Mardorf wrote:
The tone has changed. This distorts the significance of stable, release-
based non-CVS packages compared to CVS packages. I have no idea how to
respond to this:
" morsmortium commented on 2026-09-27 11:02 (UTC)
I will not argue this anymore.
Someone having a crash and losing work is a larger annoyance than
someone having to do a 5 second rebuild, and this happened at times.
It will get reduced over time, when the library will become more stable.
If you think this is so large of a violation of the guidelines, you are
free to send an orphan/adoption request and make Arch staff decide it."
- https://aur.archlinux.org/packages/gtk-nocsd-git
Ralf,
I am just an accountant and have in general no idea what I am doing,
but I have been facing this very same problem on both sides of the
equation:
1) for any reason there are version numbers (and everybody wants to
understand them as "stable" or "secure")
2) while the developer pretty much runs it as rolling release where
every commit is the latest greatest version per definition (<-- that's
usually me 😄 )
I have solved it by deriving a minor or minor-minor version direct
from the GIT build number per `git describe` and so creating pseudo
"stable" releases (instead of just calling it a "-SNAPSHOT").
So JSQLParser 5.3 (stable) became JSQLParser 5.3.719 (which in fact
was the 719 commit after the 5.3 release).
And I am doing the same now for AURSCAN, since "-git" was also not
compatible with some package guidelines.
Maybe this can help you to find a workaround because I actually do
understand morsmortium's point.
Best and cheers
Andreas
