On 12/18/17 14:01, Rich Freeman wrote: > 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. interesting point of view but this would require major refactoring of portage and providing a resilient and capable infrastructure to serve the ebuilds on demand. Removing just files/ dirs would require no modification to portage and a load on infra that is probably much lighter (dependant on implementation chosen)
> 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. Personally, most of the time I do see them exactly this way, but not a big fuss either > > 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. Provided exact source of upstream files is kept near the ebuild the idea is tantalizing. A per repository base SRC_URI and "automatic" downloads of packages files > > 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. > another good point, it would be probably a good time to split $DISTDIR in per package directory, big number of inodes in that dir has also been a source of problems in the past, especially for mirror owners.
