Arch Linux User Repository

(2) By doing it like this, AUR helpers gain a means to detect version updates, since a new commit manifests in the AUR version number. Without it, we're enabling one of two scenarios, and both lead to really awkward user experiences:

(a) Users need to remember that they want shiromino-git updated and do so manually, even if their AUR helper is perfectly capable of detecting a new version. That's pretty much the exact opposite of how a package manager should behave.

(b) Us maintainers need to remember to update the shiromino-git package on every upstream commit, or else (a) happens. And if we forget, the version users see when they query the AUR will never be the version that gets installed, which just adds to the confusion.

Scimmia is correct. An unauthorized user removed the guidance to not do this, from the page. Scimmia restored it.

What you are doing is a violation of the AUR rules of submission. Speaking with my TU hat on, I've suspended the account of your bot for infracting the rules.

You'll get it reactivated once you comply with my requirements.

• you must use the pkgver() function
• you must not use a bot to update the pkgver on every commit
• you may use a bot to push new pinned versions of a package named e.g. shiromino, or to push new versions of this package only when some part of the template other than the pkgver has changed

For VCS packages such as *-git, the user is expected to use the --devel flag of many AUR helpers, or otherwise periodically check if the package can be rebuilt.

You may optionally provide an Unofficial user repository which builds the latest commit by running the pkgver() function and uploads the result to a file server, if you'd like users to get updates "how a package manager should behave".

And if you'd bothered to read the comment I left when editing, I was restoring information that another user had incorrectly removed.

Scimmia: We've done a fair bit of reading when making this package, and nowhere did it say that bumping $pkgver is against the rules. In fact, the very page in the Arch Wiki you're referencing only includes that bit because you've personally edited that in a few hours ago, as can be seen here. https://wiki.archlinux.org/index.php?title=Arch_User_Repository&diff=657802&oldid=655249

This makes it rather hard to believe you going forward.

So you say it's not a special case, but think the guidelines, and how every other git package in the AUR works, doesn't apply to you. That's the definition of thinking you're a special case.

Anyway, I don't care how you do 1, but 2(a) is how things are SUPPOSED to work. Arch is a user-centric distro, users are supposed to take some responsibility for their system. Bumping on every commit actually against the rules. https://wiki.archlinux.org/index.php/Arch_User_Repository#Flagging_packages_out-of-date

Scimmia: This project is certainly not a special case. It's just that the current infrastructure doesn't address the problems we were facing, and all I'm doing is provide a solution. Again, I'm very willing to change things if you could address the points I've brought up and help us find a way to avoid said problems.

Everyone thinks their project is a special case. It's not. Use a pkgver function and leave it alone.

Scimmia: It would be really helpful if you could tell us which of the guidelines we're not already following.

And about shiromino-bot, the problem is this: We currently maintain a template for PKGBUILD on GitHub. When our CI system detects a tagged push onto master, we fill out that PKGBUILD template and push the result onto the AUR. That approach achieves several things:

(1) We gain the ability to template the entire PKGBUILD, not just $pkgver. For instance, we can soon define $pkgdesc over at GitHub, and it gets mirrored over here. That's useful in that it minimizes redundancy, because CMake also lets you define a project description. And then there's also the GitHub project description. And as soon as we package shiromino for the next distribution, there will be one even more instances of them. I'm sure it's understandable that we're trying our best to avoid making this piece of information redundant, so being able to template PKGBUILD is quite useful.

(2) By doing it like this, AUR helpers gain a means to detect version updates, since a new commit manifests in the AUR version number. Without it, we're enabling one of two scenarios, and both lead to really awkward user experiences:

(a) Users need to remember that they want shiromino-git updated and do so manually, even if their AUR helper is perfectly capable of detecting a new version. That's pretty much the exact opposite of how a package manager should behave.

(b) Us maintainers need to remember to update the shiromino-git package on every upstream commit, or else (a) happens. And if we forget, the version users see when they query the AUR will never be the version that gets installed, which just adds to the confusion.

If your comment was about providing a pkgver function: I'm aware that it exists and how it works, but overall that feature just isn't designed very well. As far as I know, $pkgver is the only variable in the PKGBUILD that can be updated through a function, and it is simply beyond me how $pkgdesc and others don't have that ability, since it'd be extremely useful to just read the project description from CMake (or whatever else a project may use) and update the PKGBUILD accordingly.

Lastly, there's also the problem that GitHub requires the SSH key of any member of this package to be able to push to the relevant repository. I'm sure you'll understand that I don't want Microsoft to have my private SSH key. I would usually just create a separate project-related one, but the AUR would only let me enter a single one. So I'd be giving Microsoft access to control all the packages that I'll ever create, which I think is a non-starter.

For now, I think this is the cleanest we can do. But if you could provide us with a way to solve the aforementioned problems in a cleaner way, I'd be very happy to restructure things.

You really need to read this: https://wiki.archlinux.org/index.php/VCS_package_guidelines

And get rid of the bot.