As package sets are mostly done now, I'm starting to think about something else. One of my pet peeves with portage is the "packages" file in profiles, for several reasons: 1) it has two completely independent purposes 2) it implements a redundant visibility filter as package.mask is also available in profiles 3) the syntax for defining the "system" set plain sucks 4) the name doesn't really say anything about the purpose
Another issue that isn't directly related, but covered by the proposed solution below, is the so called "implicit system dependency" in ebuilds, which doesn't really exist. It only an assumption by people that the "system" set is satisfied before an ebuild is processed, so its contents don't have to be listed in *DEPEND. If a user breaks that assumption by not regulary ensuring that "system" is satisfied bugs can occur. Another issue is the informal exception when system items are allowed to/must be listed in *DEPEND, IMO that should be formalized. To solve both issues I propose the following system: Profiles can contain the files "system.depend" and "system.rdepend" whose combined contents make up the "system" target. If any of those two files exists the "packages" file is ignored. The syntax should either be the same as package.mask or, if desired, also allow complex atoms (use-conditionals, any-of constructs). The second part would be that portage implicitly adds the content of the files to the DEPEND or RDEPEND setting of each ebuild unless it contains RESTRICT=system-deps. Obviously this would have to be tied to a new EAPI version. (an undefined cornercase here is if a profile does not contain the new files, not sure how that should be handled) Benefits: - we get rid of all the issues outlined at the top - should make it easier long-term to setup a no-compile system that only installs binary packages due to separation of build- and runtime deps in "system" Problems: - obviously it has to be implemented first - no obvious solution for stacking rules (e.g. child uses system.*, but parent profile only has "packages") - some people might rely on the "packages" file So, comments? Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better.
signature.asc
Description: PGP signature
