| 1 |
(I hope this makes it to the -dev list) |
| 2 |
|
| 3 |
Hello everyone - |
| 4 |
|
| 5 |
I'm not an official dev but frequently report bugs, fixes and also |
| 6 |
maintain a few go-based ebuilds in my private overlay. I also hate |
| 7 |
golang with the force of a thousand suns, but hat's not important |
| 8 |
right now. |
| 9 |
|
| 10 |
Since I recently converted all my ebuilds from EGO_SUM to the |
| 11 |
tarball way of doing things I'd like to chime in. |
| 12 |
Also I'm not going to rehash everything that has been said, except |
| 13 |
maybe that the space usage of the tarballs is nothing short of *insane*. |
| 14 |
|
| 15 |
OTOH having to paste a weird list of dependencies into the |
| 16 |
ebuild is also insane, even though get-ego-vendor makes this |
| 17 |
palatable. With an eye towards fixing *that* with a bit more |
| 18 |
automation, let's look at the pieces of the puzzle. |
| 19 |
|
| 20 |
The candidate on the table: the ebuild for restic, a popular |
| 21 |
and pretty clever backup program. |
| 22 |
|
| 23 |
The restic ebuild by itself is ~40k: |
| 24 |
$cd /var/db/repos/gentoo/app-backup/restic |
| 25 |
$ls -al restic-0.13.1.ebuild |
| 26 |
-rw-r--r-- 1 root root 40699 Apr 23 13:11 restic-0.13.1.ebuild |
| 27 |
|
| 28 |
If we separate the ebuild from the EGO_SUM blurb, we get: |
| 29 |
$ls -al restic-0.13.1* |
| 30 |
-rw-r--r-- 1 holger users 39668 Jun 14 17:50 restic-0.13.1-EGO_SUM |
| 31 |
-rw-r--r-- 1 holger users 1030 Jun 14 17:51 restic-0.13.1.ebuild |
| 32 |
|
| 33 |
Nothing new here. But how large is the EGO_SUM really? |
| 34 |
$ls -al restic-0.13.1-EGO_SUM.bz2 |
| 35 |
-rw-r--r-- 1 holger users 7902 Jun 14 17:50 restic-0.13.1-EGO_SUM.bz2 |
| 36 |
|
| 37 |
Much smaller obviously, but probably still too large for including in |
| 38 |
$FILESDIR. So my idea here is: instead of chucking EGO_SUM (automatically |
| 39 |
generated declarative dependency management) out the window, can we not |
| 40 |
separate the two and instead of uploading the tarball upload the |
| 41 |
dependency set instead? This does not fix the mentioned trust problem |
| 42 |
since a dev space can still be hijacked, but that is already the case. |
| 43 |
Anyway. |
| 44 |
|
| 45 |
The only new requirement here would be to load/parse the EGO_SUM.bz2 into |
| 46 |
the ebuild, but I'm sure that can be solved. Note that only the SHA of |
| 47 |
the EGO_SUM.bz2 would be verified as dependency, not all the |
| 48 |
contents - same as with the tarball. |
| 49 |
|
| 50 |
This would eliminate the space bloat/bandwith amplification problem, |
| 51 |
distfile caching across ebuilds could again work as expected (even though |
| 52 |
go successfully makes that almost futile), and with slightly better |
| 53 |
tooling in ego-get-vendor could reduce toil when bumping an ebuild. |
| 54 |
|
| 55 |
I'm looking forward to hear why this idea is terrible. :) |
| 56 |
|
| 57 |
Thank you all for Gentoo. |
| 58 |
|
| 59 |
cheers |
| 60 |
Holger |
Archives