1 |
On Sun, Feb 13, 2022 at 07:37:33AM +0000, Robin H. Johnson wrote: |
2 |
> |
3 |
> "just repackage it" |
4 |
> - Is that in line with the licenses of ALL of distfiles? |
5 |
> - If the combined gentoo-specific distfile is 100MB per $PV, you're now |
6 |
> forcing 100MB of new downloads for each version. |
7 |
> - Is it easy enough for any overlay author to use? |
8 |
> - How are you going to trust every overlay's repacking of the distfiles: |
9 |
> that they didn't include malicious code in the distfile, that wouldn't |
10 |
> be caught in a review of the ebuild? |
11 |
> |
12 |
> I haven't done a full analysis of how much space it would end up take, |
13 |
> |
14 |
> But as a quick version, let's consider Vault 1.8.x series. |
15 |
> |
16 |
> vault-1.8.6 -> vault-1.8.7 didn't change distfiles. |
17 |
> vault-1.8.7 -> vault-1.8.8 |
18 |
> |
19 |
> 1.8.6 -> 368MB worth of distfiles |
20 |
> of which 22-24MB are different from 1.8.7 & 1.8.8 |
21 |
> |
22 |
> So naively, if you re-packaged those 3 versions, 368MiBx3 => 1104MiB on |
23 |
> the mirrors. |
24 |
> |
25 |
> Or just 413MiB of unique distfiles between the versions. |
26 |
> |
27 |
|
28 |
If felt necessary on some larger packages that release often, could |
29 |
always do increments/patch to the previous tarball (just untar changes |
30 |
over if possible to be simpler). Can be merged in a single one on major |
31 |
versions. |
32 |
|
33 |
Similar to what gentoo-sources does right now by only making users |
34 |
download linux-5.16.tar.xz and patch it up to 5.16.9, not that it'd |
35 |
need to go as deep or use patches for easier maintenance. |
36 |
|
37 |
We'd control the tarball anyway so we can manage it how we see fit. |
38 |
|
39 |
> So save your 18MiB of disk space of Manifest lines, or 691MiB. |
40 |
|
41 |
As long as Manifest is on every users system (on a package that |
42 |
they may never use no less), that 18MB feels a lot bigger than |
43 |
691MiB to me. Mentioned before, but we even have a rule for <20kB |
44 |
patches an and yet Manifests are growing in the 500kB and ebuilds |
45 |
100kB too. |
46 |
|
47 |
Not to say every single ebuild with small files should be refactored |
48 |
(many are reasonable) but there are a few that really stand out, and |
49 |
finding ways to allow them to be even bigger (arg/env fixes) or bypass |
50 |
the package manager (alternate fetch like unkeyworded live ebuilds) |
51 |
doesn't feel right. |
52 |
|
53 |
It's not optimal but tarball is at least feels like a viable option |
54 |
that doesn't change everything upside down. |
55 |
|
56 |
wrt overlays, easiest is typically to throw your vendored deps on |
57 |
github/gitlab and let them generate the tarball. Allows for some |
58 |
easier tracking of what they contain too. |
59 |
-- |
60 |
ionen |