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