Automatic AUR upload

[muflone]

Describe the bug

@GameTec_live please avoid to publish automated packages on AUR with no changes.

This package must be named chameleonultragui-git, providing a pkgver() function and without any automatic bump whatsoever.

I'm not yet deleting it as I want to be sure you to read this and don't auto-publish it again.

Please answer me about this acknowledgment

https://wiki.archlinux.org/title/VCS_package_guidelines

[muflone]

I've left you the same comment on the AUR package

https://aur.archlinux.org/packages/chameleonultragui#comment-964705

[GameTec-live]

ofcourse ill have to follow this request, but i have 2 questions: 1) How is one supposed to know that a update/change happened then? Most AUR helpers afaik dont check git packages for updates. (Thats the main reason of it being the way it is rn, so that a helper like yay will just update and the app doesnt get stuck on a old version)

and 2) How is the automatic publishing much different to me manually commiting a version change when a new update drops... (Or, if i provide prebuilt binaries, id still just change the package version and maybe the link to the binary)

[muflone]

The VCS packages are meant to be updated from the user on his request, some tools have an argument --devel for such type of packages

The scope for this issue is to avoid the auto-bumping. Whenever a user update the *-git package the pgkver() is run, calculating the most updated version and download the most recent git commit (HEAD).

No automatic or manual bumps are required.

[GameTec-live]

No automatic or manual bumps are required.

Then what does basically every package do? Dont they just provide a prebuilt binary and then manually bump the version?

[muflone]

VCS packages are not bumped until there's a strict need, for example when dependencies or build instructions change.

Non-VCS packages are bumped from authors, pointing to a very specific version, not the git HEAD, with no pkgver() but with a fixed pkgver variable. The pkgver variable usually points to a fixed tag/release for the repository

[GameTec-live]

so if i had github actions create a tag and then pointed the package at a tag it would have been fine? lol

[muflone]

if those tags are specific versions, not just the tip of the head, yes

[GameTec-live]

what counts as a specific version? The HEAD at the point of tag creation would be a specific version, wouldnt it?

[muflone]

what counts as a specific version? The HEAD at the point of tag creation would be a specific version, wouldnt it?

of course not, the HEAD is not a specific version, it's merely the latest commit, this is what a VCS package is

A tagged version is a release made from the author pointing to a very specific point in the history, not just the latest commit.

In the case you misuse the tags like commits, you're simply stressing the AUR users with useless updates

[GameTec-live]

of course not, the HEAD is not a specific version, it's merely the latest commit

Wheres the difference between a tag pointing at the HEAD at a specific point in time and a tag pointing to "very specific point in time"? At some point every* commit was the HEAD at some point?

In the case you misuse the tags like commits, you're simply stressing the AUR users with useless updates

Ofc thats not my plan (i alrdy commented out the workflow, etc), but im wondering as this isnt really clear to me what exactly would count as what...

And i wouldnt call what i did "stressing the AUR users with useless updates" but notifying them of a update like any other package does... Not many users will explicitly update a git package; having a "$aurhelper -Syu" also update this app when a new PR got merged (usually bringing a bug fix or new feautre), minimizes useless bugreports of bugs that are already fixed and similar issues that come with running an outdated app 🤷

[muflone]

https://git-scm.com/book/en/v2/Git-Basics-Tagging

Whenever you'd do three updates in a single day, you'd push 3 updates to your users, this is stressing the users with useless updates.

Every stable software has releases with versions, ready to be used to the users.

The git head is used for unstable experimental software, giving the user the freedom/responsibility to update to the latest version whenever they want, not when the maintainer has decided to push a new commit for them.

The git tags point to a very specific version, usually a named version, not the latest commit. Each software and each package you use has a version, a specific version used to communicate in both ways, the user communicate the author the version and the author communicate the users that is a ready to use version.

You're mixing the two concepts.

[GameTec-live]

Whenever you'd do three updates in a single day, you'd push 3 updates to your users, this is stressing the users with useless updates.

I havnt recived any complaints from my users yet, nor do i know of anyone who updates 3 times a day... Anyways; so the problem is that my app development model is ""wrong""? My main branch can be considered stable ish, atleast as stable as this small app is reasonably going to get, so thered be no point in making releases or similar, as basically every PR merge could be one, as they usually bring Bugfixes and/or new features which users want/are expecting -> therefore theyd ideally get published immideatly. In the rare case that the main branch is unstable (due to some change in the flutter toolchain or other dependency for example), then the pre publish build will fail anyways, not pushing any update...

But ok, thanks for your time... Ive followed through with your request and disabled the workflow and marked the package out of date. Maybe itll be rewritten to then push releases to the AUR, if we ever do releases... (as from what your telling me, auto pushing releases would be absolutly fine?)

[muflone]

Maybe itll be rewritten to then push releases to the AUR, if we ever do releases... (as from what your telling me, auto pushing releases would be absolutly fine?)

Automated publish is not a problem if you check your package, not only if it builds but if installs, starts and works properly.