You are not logged in.
Pages: 1
Hello,
Probably the wrong forum, but I am a complete Arch newbie, so forgive me.
I am one of the devs of Bitfighter (http://bitfighter.org), which you have an old version of here: https://aur.archlinux.org/packages/bitfighter/
I'd like to know if there is a way for me to automatically or manually trigger a rebuild when a new version is available, as there is now.
If it's not too much work, I'd love to help keep you guys up to date.
Thanks!
Offline
You can register in AUR and flag bitfighter out-of-date, thus informing its maintainer that there's a new release.
Offline
So, if I did that, it would be a process of reflagging every time we do a release?
Last edited by generalwatusimoto (2013-02-18 21:34:15)
Offline
Or contact the maintainer by mail.
To know or not to know ...
... the questions remain forever.
Offline
Yes, that is correct. The mantainer either sees that it is flagged out of date or finds out himself. Then, they update the PKGBUILD file to build the new version.
Offline
You need to flag it out-of-date every time you do a release, unless someone manages to flag it before you or the maintainer realizes there's a new release without flagging and updates the PKGBUILD (AUR holds PKGBUILDS, which are "recipes" for building packages).
Offline
Just an idea here. Would it be possible to have 'latest' tarball along with the tarballs with release versions. For example:
http://bitfighter.googlecode.com/files/ … 17b.tar.gz would be the version file but you would also have
http://bitfighter.googlecode.com/files/ … est.tar.gz alongside it, and the latest will always be the newest version.
That way, you can ask the maintainer to point the pkgbuild to the http://bitfighter.googlecode.com/files/ … est.tar.gz and it will always be the newest version whenever someone installs through AUR. That would bypass the need for communication between dev <-> maintainer to update for every release.
Offline
Ok, I've flagged it, and added that step to our release checklist. It would seem cleaner (for the maintainer) if there were a way to automate the process a bit (we post our source at a consistent URL, for example), but I can live with manually flagging it and letting the maintainer do the work.
Thanks!
Offline
@frank604 -- good idea; we'll start that with our next release.
Offline
Just an idea here. Would it be possible to have 'latest' tarball along with the tarballs with release versions. For example:
http://bitfighter.googlecode.com/files/ … 17b.tar.gz would be the version file but you would also have
http://bitfighter.googlecode.com/files/ … est.tar.gz alongside it, and the latest will always be the newest version.That way, you can ask the maintainer to point the pkgbuild to the http://bitfighter.googlecode.com/files/ … est.tar.gz and it will always be the newest version whenever someone installs through AUR. That would bypass the need for communication between dev <-> maintainer to update for every release.
That can risk screwing up the build. If there are changes to the process of building the program, the package will fail to be made. So, the maintainer still needs to keep themselves informed about the program.
Offline
That doesn't really help, though, as the maintainer still needs to change the pkgver and the checksum to make things work.
Offline
If you're willing to be involved, you could ask the current maintainer if you could take over the AUR package.
You'd have to learn how to write a PKGBUILD for arch if you haven't before - but they are very easy. Then you'd just update the AUR whenever you wanted. When you have an updated version it would take all of a minute or two to update the AUR ... probably a lot less time that even writing an email to the current maintainer, defintely a lot less than waiting for their response.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Can't you just make a "latest" version and build from hg?
https://wiki.archlinux.org/index.php/Ar … guidelines
Offline
I am not knowledgeable about maintaining packages and I was also thinking there might be a fault with the "latest" idea. Just thought people more knowledgeable would be able to chip in and point out the potholes. Trillby's idea sounds the best though. Even if the "latest" idea works without a hitch, always nice to be in full control in case of any unforeseen hickups.
Offline
Pages: 1