I don't know if this is the right place to write this but here it is (I'm newcomer to Arch).
Wouldn't it be nice to have a build counter for every package in AUR?
It could work similar to voting system.
When you install a package, say with yaourt or packer, at the end of installation and if successful, it could run something like aurvote
to increase the build count of the package.
On the package's page we could have that build count or some more info like how many builds were successful (for example) the last 10 tries or 1 month or something like that.
I believe it would be nice because people would know before choosing a package to install if it has a good chance to be built.
It could also reset the counter every time a package is being updated (so you won't have the problem that an up to date and working package is falsely reported as not good).
Thank you for your time, and sorry for my English.
(Also I think it would be nice if you click the name of a maintainer to redirect to his profile page so you could easily contact him by message, email or IM.
If you like the idea but don't like spending time implementing it, I could try to make it happen but you would need to point me to the right direction.)
If there are no comments about build problems, then a package has a high chance to build.
The problem is: makepkg does not know, where the PKGBUILD comes from. wget does not leave any traces about the origin of the file and neither does links, elinks and lynx. You would have to manually vote for the package and vote as "installed correctly". We already have a voting mechanism, people simply do not really use it as much as they should. They are way too conservative in their votes or maybe way too lazy. I would really stick with the AUR comments to figure out possible problems with the package.
The name of the submitter is clickable, once you are logged in to the AUR page.
EDIT: Oh, by the way... 8 of 10 times a package fails to install (in my case) installing it manually without a helper showed me why. Your system would probably encourage people to try the package in yaourt and forget about it, instead of actually fixing stuff.
Last edited by Awebb (2014-07-22 10:26:16)
Other downsides would be that it could be meaningless. I could build my own package over and over. And as Awebb already aluded to, I'd suspect those 8 out of 10 times the build fails it is user error - not anything to do with the PKGBUILD.
So the proportion of failed builds would represent much less about the package itself that it would about how much it is marketed to 'the least common denominator'.
I see a couple of problems with this:
that the package builds is one thing, there still may be issues with packaging, runtime dependencies, different architectures, etc.
if I see that the last 10 attempts of people failed to build package, then my question is... what can I do to fix it (presumably because I really want the software), what have others done about it
I like the simple straight-forward approach:
read the latest comments on the AUR package
check the time it was updated to see if it's not likely to be outdated
if it is outdated, report as outdated, with new PKGBUILD if you can
try to build the package
if it fails, and you have a time and know-how, fix it and report on AUR in form of comment with PKGBUILD fix
otherwise, document the fact that it doesn't work in form of comment (bug report with all relevant information) on AUR
So in summary, I don't see much of a benefit to see such information.
There's also the point that with packages with larger build times (such as kernel packages), there may already be a repository for people to use to avoid the larger build time (take the myriad of CK kernel packages built by graysky).
And while I'm on it, graysky's CK kernel packages are quite a fun case because there is the generic build, the architecture specific build AND the AUR package. How would you track those?
Last edited by clfarron4 (2014-07-22 11:37:01)
Other downsides would be that it could be meaningless.
Merely knowing that a package failed to build for an individual is meaningless. Full stop. There are several steps involved in solving a problem, including (but not limited to):
- Observing an apparently problematic phenomenon.
- Confirming that a problem actually exists, and isn't an anomaly
- Identifying what the problem is and what effects it has
- Figuring out what precisely needs to change to correct the problem
- Figuring out how to change what needs to be changed
A phrase like "Builds: 8/10" or "2 build failures" does one of those, while neglecting the rest. Again, merely knowing that someone, somewhere, had trouble with something at some time doesn't mean anything. The best way to find and solve problems with AUR packages is to try and build them and determine if the problem is easily and immediately soluble for the user. Whether the user can solve the problem or not, the package maintainer should be contacted with details of the issue.
So I guess it's a bad idea
For a split second there I thought it would be nice for the casual user (non developer) to be able to quickly determine if he have a good chance with an aur package.
But I do get that there could be many user defined sources of build fails (though for me PKGBUILD's work really nice, except for some that haven't been updated in ages and are orphaned).
@Awebb "We already have a voting mechanism, people simply do not really use it as much as they should. They are way too conservative in their votes or maybe way too lazy."
Why do you think this is so?
I will tell you why I didn't vote in many packages.
At the time I used yaourt to install AUR packages, I had installed aurvote, BUT yaourt asked me to vote right after a package was installed. Which is nice, but I couldn't know beforehand if the program would run correctly, for example it could build just fine and then when you try to run segfault in every try. I wouldn't like to vote on that
So the way yaourt handles the voting is one source of reluctance to vote.
Anyway, again, thanks for your time.
So the way yaourt handles
the votingeverything is one source of reluctance to votereason not to use it.
while read -r pkg; do printf "%s: " "$pkg"; aurvote -c "$pkg"; done < <(pacman -Qqm)
That surely is helpful.