Re: [SOLVED] Re: [gentoo-user] Ebuild: How to deal with external repositories properly (best practise)?

[Rich Freeman]

On Tue, Aug 4, 2020 at 6:57 PM Alexey Mishustin <shumkar@×××××××.ru> wrote:
>
> вс, 2 авг. 2020 г. в 13:52, Ramon Fischer <Ramon_Fischer@×××××××.de>:
> >
> > I decided to use "EGIT_COMMIT" to let the ebuild pulling a certain commit.
>
> And even that would not give the sense of security...
>
> Just read in gentoo-dev [1]:
> ...unannounced serverside change by GitHub, which broke download of
> tarballs by git-tree-hash, e.g. previously https://
> api.github.com/repos/JuliaLang/MbedTLS.jl/tarball/
> 2d94286a9c2f52c63a16146bb86fd6cdfbf677c6 would give the tarball for
> that tree- hash, while it now gives the tarball for master instead.
>

I'm pretty sure EGIT_COMMIT will fetch by commit ID using git, not
download a hash-labeled tarball, so I don't think this issue would
impact you if that is how you're fetching things.

If you did use a hash tarball with SRC_URI and a conventional
download, then emerge would still refuse to use the tarball if it
failed the manifest hash check, so it wouldn't be installing anything
you didn't want.

Generally this isn't going to immediately break anything used by the
Gentoo repo since 99% of this stuff will be mirrored, and the mirrors
check hashes too.  So, when github breaks the download link the
mirrors will preserve their existing tarballs and refuse to replace
them with new ones that don't have a matching hash (I'm talking about
the actual hash of the file using multiple algorithms, not the hash in
the filename).  When you fetch from a mirror you'll still get the
correct version of the file.  If for some reason you can't reach any
mirrors then you would download the broken link from github and then
emerge would reject the file due to hash mismatch.

Still, unless github fixes this we'll probably have to fix a bunch of
links in the repositories - at least any based on hashes.  I'm not
sure if this impacts tags.  The SRC_URIs are still invalid and we
don't want to maintain that state as new mirrors won't be able to
retrieve the file, and we generally want a valid SRC_URI for
everything.  Devs can always just upload the tarball to any random
webserver and change the URI to point to it.  My guess though is that
everybody will want to give this a few days to see if github fixes
their links.

Really this could happen with any web hosting service - github is just
a really prominent one.  Back in the day if sourceforge suddenly went
down a whole bunch of SRC_URIs would have broken too.

-- 
Rich