[aur-general] Question about AUR submission rules

[networkException]

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