[aur-general] TU Application: Baptiste Jonglez

[Levente Polyak]

On 11/29/2016 11:33 AM, Baptiste Jonglez wrote:
> For a package in [community], an expired certificate for the upstream
> tarball is not a big deal, since it does not directly affect the Arch user
> installing the package.  As a packager, you can just get the tarball by
> some other means, or wait a few days so that somebody renews the cert.
> 
> But for the AUR, an expired certificate would be annoying, as any user
> trying to build the package (e.g. using an AUR helper) would encounter an
> error.
> 

I call bullshit, especially as your cases are purely about github!
Surly, as if they can't wait "a few days" in such an unlikely scenario.
And what if upstream forgets to pay for their servers, it won't be
available too.
How often do you think that certificates stay in an expired state. Of
cause there may be one or two cases that could be named, its still
certainly nothing to build upon.


>> I never get why people always make such a big fuzz in not pulling over TLS.
>> The same argumentation could be used for the regular tarballs and I
>> repeat, the outcome is simple: use https, easy as that.
> 
> Well, I agree with the outcome of the discussion, which was basically "One
> way or the other does not change much security-wise, so let's switch to
> HTTPS if doing so does not require significant efforts".
> 

Fine, if you were already aware of the outcome, why this useless waste
of time to discuss it yet again. Especially a TU applicant should follow
chosen best practices and decisions. The AUR should not be any different
from how they should be in the binary repos, so I expect to see those
changes in your packages as well.

>>
>>>> libringclient-git
>>>> - a VCS package should always provide its non-VCS package variant like
>>>>   'libringclient'
>>>> - If there is no strong reason to depend on a git variant, always depend
>>>>   on the non VCS, in this case ring-daemon instead of ring-daemon-git
>>>
>>> See the above comment on gnome-ring-git.
>>
>> And here is the -git hell I describes, either take all -git or none...
>> that's not how it should be. Think how it would be if every library
>> would be like that, that would mean you need to use -git for the whole
>> system just because you switch a single package. Don't enforce it just
>> because... if such happens people will figure.
> 
> Again, the constraints are a bit different on the AUR and on a binary
> repository.  What I try to ensure is that somebody running e.g. "yaourt -S
> ring-gnome-git" will not have compilation issues.  If ring-gnome-git
> depends on libringclient, then the former will not build if the API
> provided by libringclient has changed recently.
> 

Again, even through there are quite obviously no -git packages in the
binary repository, the PKGBUILDs in the AUR should not be created in a
different way then you would write them in the binary repo. Also AUR
packages are influenced by each other and just completely abandon all
provides is clearly a very bad practice. As easy as that.

https://lists.archlinux.org/pipermail/aur-general/2016-October/032845.html

cheers,
Levente

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20161129/549a561d/attachment.asc>