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