[aur-general] Question about AUR submission rules
Hello, 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. 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. 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. 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". 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 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). Thank your for taking the time to reading, I hope it will be possible to find a way to submit ungoogled-chromium-bin properly. Kind regards, networkException
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
On Thu, Sep 23, 2021 at 11:57:03AM +0300, Alexander Epaneshnikov via aur-general wrote:
On Wed, Sep 22, 2021 at 08:37:23PM +0200, networkException via aur-general wrote:
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.
Arch strives to deliver unpatched software. Packaging something like ungoogled-chromium is antithetical to this goal, and I struggle to see why we should make an exception for this package. (This is also from someone that looks at ungoogled-chromium as only a performative thing, it doesn't actually get you anything in terms of security nor privacy. Obviously someones opinion might differ :p) The current situation is clearly not ideal, and I don't see any good solutions. I'd maybe see if we can make an exception for ungoogled-chromium-bin as the pragmatic option, thus allowing it to repackage .pkg.tar.zst. -- Morten Linderud PGP: 9C02FF419FECBE16
On Thu, Sep 23, 2021 at 11:09:30AM +0200, Morten Linderud via aur-general wrote:
On Thu, Sep 23, 2021 at 11:57:03AM +0300, Alexander Epaneshnikov via aur-general wrote:
On Wed, Sep 22, 2021 at 08:37:23PM +0200, networkException via aur-general wrote:
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.
Arch strives to deliver unpatched software. Packaging something like ungoogled-chromium is antithetical to this goal, and I struggle to see why we should make an exception for this package.
yes, it does sound logical.
(This is also from someone that looks at ungoogled-chromium as only a performative thing, it doesn't actually get you anything in terms of security nor privacy. Obviously someones opinion might differ :p)
The current situation is clearly not ideal, and I don't see any good solutions. I'd maybe see if we can make an exception for ungoogled-chromium-bin as the pragmatic option, thus allowing it to repackage .pkg.tar.zst.
I personally do not mind, but as I said earlier, it is difficult for me to imagine an arch linux user who will not be able to add a repository. and of course the idea of repackaging the package is simply not pretty in my opinion.
-- Morten Linderud PGP: 9C02FF419FECBE16
-- Sincerely, Alexander | Trusted User
Hello again, thanks for replying to my question. I have a few comments / follow up questions regarding the topic. On Thu, Sep 23, 2021 at 11:57:03AM +0300, Alexander Epaneshnikov via aur-general wrote:>> 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?
I feel like there is enough documentation about how to add the OBS repository, people still seem to prefer using the AUR. It's convenient to them as they most likely already have an AUR helper installed so it's just a single command. On Thu, Sep 23, 2021 at 12:21:44AM +0300, Alexander Epaneshnikov via aur-general wrote:
On Thu, Sep 23, 2021 at 11:09:30AM +0200, Morten Linderud via aur-general wrote:
On Thu, Sep 23, 2021 at 11:57:03AM +0300, Alexander Epaneshnikov via aur-general wrote:
On Wed, Sep 22, 2021 at 08:37:23PM +0200, networkException via aur-general wrote:
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.
Arch strives to deliver unpatched software. Packaging something like ungoogled-chromium is antithetical to this goal, and I struggle to see why we should make an exception for this package.
yes, it does sound logical.
(This is also from someone that looks at ungoogled-chromium as only a performative thing, it doesn't actually get you anything in terms of security nor privacy. Obviously someones opinion might differ :p)
The current situation is clearly not ideal, and I don't see any good solutions. I'd maybe see if we can make an exception for ungoogled-chromium-bin as the pragmatic option, thus allowing it to repackage .pkg.tar.zst.
I personally do not mind, but as I said earlier, it is difficult for me to imagine an arch linux user who will not be able to add a repository. and of course the idea of repackaging the package is simply not pretty in my opinion.
I wasn't aware of this goal of Arch and I also see that the lines what should be in an official repository and what not are blurry. Personally I would say that ungoogled-chromium has enough features to set it apart from just a patchset to improve performance but my opinion is obviously biased here :^) If a trusted user would be willing to maintain a community package it would be a great improvement to anyone wanting to use ungoogled-chromium on Arch. On Thu, Sep 23, 2021 at 11:57:03AM +0300, Alexander Epaneshnikov via aur-general wrote:
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.
Alright I will probably create an archive that does not contain makepkg metadata files for ungoogled-chromium-bin if a community package will not be created. Thanks again for the feedback you both! Kind regards, networkException
participants (3)
-
Alexander Epaneshnikov
-
Morten Linderud
-
networkException