| 1 |
On Mon, 2022-05-16 at 19:37 +0200, Markus Walter wrote: |
| 2 |
> Hello all, |
| 3 |
> |
| 4 |
> is it possible to do the following: after fetching a distfile portage runs |
| 5 |
> an external normaliser program specified in an ebuild before checking the |
| 6 |
> hash? |
| 7 |
> |
| 8 |
> My use case is the following: I would like to improve the gs-elpa program |
| 9 |
> and provide a precomputed overlay for melpa. However the melpa distfiles are |
| 10 |
> rebuilt everyday and cause checksum failures. However the only thing |
| 11 |
> changing are the timestamps. Hence if a normaliser program could simply set |
| 12 |
> all timestamps to some predefined value (say 1.1.1970) then this problem |
| 13 |
> should vanish. |
| 14 |
> |
| 15 |
|
| 16 |
This would require a new EAPI. We don't really want more Portage- |
| 17 |
specific hacks that are going to break for everyone not using Portage or |
| 18 |
the very specific Portage version. |
| 19 |
|
| 20 |
I'm not saying that it's not doable but I'm not convinced the added |
| 21 |
complexity is really worth the effort, especially given that this looks |
| 22 |
like a very special corner case. In the end, fixing Melpa is the right |
| 23 |
thing to do. |
| 24 |
|
| 25 |
For a start, you'd have to ensure that the "normalizer script" (or its |
| 26 |
dependencies, if you put it in the repo) is available at the time of |
| 27 |
fetching. This pretty much goes back to the problem of "fetch |
| 28 |
dependencies", and requires a major design change in Portage that |
| 29 |
reduces separation between fetching and installing that we have now. |
| 30 |
I mean, right now Portage pretty much assumes that you can do |
| 31 |
a `--fetchonly` with no extra packages necessary. |
| 32 |
|
| 33 |
The "normalizer" wouldn't be trivial either. In the end, we're talking |
| 34 |
about getting 100% consistent results on all platforms, over |
| 35 |
a reasonably long timeframe. |
| 36 |
|
| 37 |
-- |
| 38 |
Best regards, |
| 39 |
Michał Górny |
Archives