[aur-general] Question about AUR submission rules

[Alexander Epaneshnikov]

On Wed, Sep 22, 2021 at 08:37:23PM +0200, networkException via aur-general wrote:
> Hello,

hello. here is my position on this matter.

> I maintain the ungoogled-chromium packaging for Arch Linux as an officially
> supported platform. As a quick overview, ungoogled-chromium is a set of
> patches that aims to remove all dependencies on Google services from
> Chromium.
>
> Compiling Chromium is a quite resource and time intensive task, which is why
> I use both Open Build Service and GitHub Actions for offering binary
> releases.

I agree and this is a good decision.

> As the packing is Arch Linux specific, both build systems produce a package
> archive for pacman.
>
> A highly requested feature by users is to offer such a binary release in the
> AUR as it is more convenient for them compared to adding a custom repository
> for example.

I find it difficult to understand why adding a repository is inconvenient.
maybe it is worth creating more documentation explaining how to do this?

> In the past there were already ungoogled-chromium-bin packages in the AUR,
> usually submitted by people not affiliated with the project and removed for
> some reason at some point in time. The most recent one would download a
> pacman package from an OBS repository and install it by extracting files
> manually.

looks like a hack. I would probably removed this package too.

> In the delete request removing this last package (#19142) it was stated that
> "the AUR is not intended to provide an index for PKGBUILDs that repackage
> the
> build package originally created by another PKGBUILD".

I also agree with this statement.

> While I understand
> that
> the AUR would want to avoid to just include repackaged entries like that, I
> am
> now wondering what the best way to offer a binary package in the AUR would
> be
> in my situation.
>
> Building Chromium separately into a non makepkg archive just for the AUR on
> GitHub Actions for example seems wasteful and would defeat the way package
> checksums are currently handled, as such making it harder for end users to
> quickly verify that the binary an AUR helper for example would download is
> legitimate.

I think this is the best option. you can sign archives with pgp key and
check them when building.

> I tried looking for a rule that explicitly states the mentioned repackaging
> restrictions, but I was unable to find one. I have also found another AUR
> package which is normally available that repackages a pkg.tar.zst
> (codelite-bin).

I think there really is no such rule. however, it seems to me that such things
are logical enough and do not need explicit rules.
also finding another package that does wrong things is not an excuse for
those wrong things.

> Thank your for taking the time to reading, I hope it will be possible to
> find a
> way to submit ungoogled-chromium-bin properly.

thank you for asking for advice.

I also thought, why not move ungoogled-chromium to the community
repository, if, of course, the inclusion criteria are met.
I think this is also not a bad solution to the problem.

> Kind regards,
> networkException

--
Sincerely, Alexander | Trusted User
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 6184 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20210923/c496a49b/attachment.sig>