On Fri, Jun 12, 2015 at 4:34 AM, Lukas Fleischer <lfleischer@archlinux.org> wrote:
On Fri, 12 Jun 2015 at 01:42:41, Eli Schwartz wrote:
[...] That still requires packagers to go through several new hoops. [...]
Which ones? Can't think of any apart from generating the key and adding it to the web interface. It literally takes ~1 minute. You need to do the same thing after creating an account on a Git hosting platform like GitHub.
And I can see the benefit of allowing tarball uploads for the same reason that the AUR3 included a web interface for adding new packages (rather than having a hard requirement for using a helper). e.g. uploading changes from another computer while traveling.
What happens if the package already exists? Say, the packager switches to a new computer.
What's the issue here? `git clone` will clone the existing repository. Might want to use some options such that it doesn't actually check out HEAD. Or have another command to pull changes before submitting.
If you work on two machines in parallel, you will get a merge conflict or a denied push, sure. But that's an inherent issue. When using the tarball submission process you would overwrite changes from the other machine which is way worse than something telling you that there is something wrong.
Does the tool also setup an ssh key and add that key to the packager's account?
No. It also does not register a new AUR account or setup your Internet connection. It submits packages to the AUR. As I said before, generating and adding the key is a tiny one-time process and automating it doesn't pay off.
[...] I would like to see a method for submitting a tarball, having the aurweb checkout the package's master branch, overwrite the index with the tarball contents, and commit that with a generic message. (e.g. "upgpkg: ${pkgname} ${pkgver}-${pkgrel}").
Aside from the need to actually spend time implementing that, is there any reason not to? [...]
Just to name a few issues:
* We would have to reintroduce the Archive::Tar library which we had several issues with in the past and were very happy to get rid of.
* You need to be very careful when extracting tarballs. It is quite easy to build ZIP bombs. This is one of the reasons we only extracted the PKGBUILD (and no other files) when the AUR submissions still required uploading source tarballs. What you suggest would require extracting everything, though.
* We would have to create checkouts for the Git repositories that are submitted via tarballs. We put a lot of time into making the storage as space efficient as possible, using a shared object storage with gitnamespaces. We can currently store the ~10000 packages uploaded so far with <40MB disk usage. Creating checkouts would mean that this increases by a factor of ~20. Creating and destroying checkouts on the fly is also quite ugly and something I would like to avoid.
* The AUR web interface is written in PHP, the Git backend is written in Python. We would either have to duplicate all the sanity checks or create some weird interface between the tools that involves reading and converting error messages from the standard file descriptors.
Also, I do not understand all the fuss about Git. We don't expect people to be a Git expert. There are a lot of tutorials and there are detailed explanations in the Arch wiki. You should be able to submit a package by only copy-pasting snippets from the wiki without even understanding what is going on.
If people really refuse to learn the five most basic Git commands, they better don't maintain any AUR packages. Maintaining packages means that you are willing to understand basic packaging and VCS tools. Tracking down issues with a package often involves using the upstream VCS and nowadays, most projects use Git.
It is expected (and intended) that some (hopefully not too many) AUR package maintainers back out due to the new system. It is also intended that a huge number of packages is not imported into the new AUR and anything that automatically transfers packages is undesirable. We only want users to resubmit their stuff if they want to take care of it in the future. Think of it as a huge AUR cleanup.
Regards, Lukas
Thanks for the explanation. :) Sounds like there really are issues beyond simply writing the implementation (which *could've* been a nice-to-have-someday request). I agree people should understand the system, and I understand the AUR is being cleaned up. I suppose it would be too much effort and stress to properly support any sort of bridge. Hopefully most AUR maintainers will switch over. -- Eli Schwartz