[aur-general] AUR4, git, subtrees ELI5?

[Eli Schwartz]

On Fri, Jun 12, 2015 at 4:34 AM, Lukas Fleischer <lfleischer at 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