On Mon, Jun 28, 2021 at 9:46 AM Michael Orlitzky <[email protected]> wrote: > > On Mon, 2021-06-28 at 15:00 +0200, Agostino Sarubbo wrote: > > > > Instead, imagine that each ebuild declares a variable called SOURCETYPE ( or > > similar, or in metadata.xml if you prefer ) and with a tool like equery/eix > > we > > are able to get the list of all packages that compiles C code. > > > > I think all you are really asking for is that we stop omitting a random > subset of @system from *DEPEND. > > This is long overdue, for many reasons, but in particular it would > force us to declare a dependency on a C compiler if one is needed and > allow you to re-test only those packages that use a C compiler.
++ - this would also support parallel building of @system. Obviously we'll still need a core set of packages needed for bootstrapping/etc, but there is no reason @system couldn't just be another virtual. You could also have convenience virtuals for things like the C toolchain and so on. This will both support alternate implementations and avoid having to have laundry lists of deps in every ebuild. A simple way to transition would be to create a system virtual and add it to all ebuilds, but ask that this be removed in future updates in favor of more specific dependencies. Over time then the tree would move to specified true deps. Catalyst could still use a virtual as a target for bootstrapping stages. Another tool that would be useful is what some other distros do - use mount namespaces/etc to allow build systems to only see parts of the filesystem (down to the file level) that are specified in dependencies. This would basically eliminate unspecified or automagic dependencies, since anything not specified basically doesn't exist at build time. If you didn't want to use mount namespaces then our sandbox already allows limiting read access to only specified files - we just configure it to allow read-only to everything for every package. -- Rich
