[aur-general] TU Application: Baptiste Jonglez

[Doug Newgard]

On Tue, 29 Nov 2016 12:08:39 +0100
Levente Polyak <anthraxx at archlinux.org> wrote:

> 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.

Git packages were not discussed, and https wasn't really "chosen best
practices", it was more "eh, why not". Getting all emotional because someone
doesn't buy into your reteric 100% isn't helping anyone.

> >>  
> >>>> 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

Reality time: The AUR is different than the binary repos. Yes, ideally the
PKGBUILD should be able to go directly to the binary repos, but reality needs
to take precedence over blind ideology. AUR packages are managed differently
than repo packages and in the vast majority of cases are built differently as
well.

I agree with you in this case, but please don't use this dubious argument.

It does make sense to depend on the -git versions in cases like this as well.
We're not talking everything, we're talking everything in a given stack
provided by a single upstream. Applying this to another example, Qt5 packages
from git should depend on other Qt5 packages from git, not on their stable
versions.

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