| 1 |
On Mon, Dec 18, 2017 at 7:45 AM, Francesco Riosa <vivo75@×××××.com> wrote: |
| 2 |
> |
| 3 |
> It would be interesting instead to evaluate ways to remove _all_ files/ dirs |
| 4 |
> from the tree, keeping ebuilds separated from data. |
| 5 |
|
| 6 |
Arguably you could go a step further and not distribute even the |
| 7 |
ebuilds except on demand. Just have an index of what packages exist |
| 8 |
and enough dependency info to avoid having to churn with ebuild |
| 9 |
fetches in order to resolve them. |
| 10 |
|
| 11 |
You could view ebuilds as source code - certainly important, but not |
| 12 |
necessarily the best thing to just have sitting around on your hard |
| 13 |
drive when not needed. |
| 14 |
|
| 15 |
Whether we remove all files/ or the entire package dir from the repo, |
| 16 |
I'd suggest that this become more standardized if we wanted to go down |
| 17 |
one of these roads. Instead of sticking something in SRC_URI and so |
| 18 |
on, it might be best if files (or packages) be kept in a standard |
| 19 |
mirrored location, and the package manager would just automatically |
| 20 |
find/fetch them if they exist and extract them to a standard location. |
| 21 |
Then any package that uses files/ can do so in a more standardized |
| 22 |
way. |
| 23 |
|
| 24 |
This also would fix some existing issues with non-upstream distfiles, |
| 25 |
where they get stored in various random locations and aren't |
| 26 |
necessarily available long-term. This has been a topic that comes up |
| 27 |
from time to time, especially if somebody is trying to build from an |
| 28 |
old version of the repo. Something like genkernel patches or whatever |
| 29 |
would just go in files/ since the size limit is now gone and they'd |
| 30 |
presumably be archived forever. |
| 31 |
|
| 32 |
-- |
| 33 |
Rich |
Archives