On Wed, 14 Aug 2013 20:57:57 +0200 Tom Wijsman <tom...@gentoo.org> wrote: > On Wed, 14 Aug 2013 19:09:40 +0100 > Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > > Er, look at the first post in the thread: > > That was about the repository, not about the PMS; the question was > whether we need to respect the PMS
Ask yourself this: if it were a Paludis-specific feature not covered by PMS instead of a Portage-specific feature not covered by PMS, would you be happy with it being put in the main tree? If the answer is no, then it shouldn't be in the tree. > and why it misses this _feature_, for which no proposed specification > exists afaik, so I don't see why you quote that implementation as a > reason for it not being in the PMS. It's not in PMS because no-one's finished the usual process for getting it into PMS. > > In order for sets to be added to the tree, we need a spec, we need > > to decide where sets are allowed (package.mask?), and we need an > > implementation. > > Sets in package.mask sounds unreliable as that would prohibit the set > from being changed as long as it masked; unless of course, the > specification would allow for a concept like "mask sets" to exist > where a particular set is denoted as masked. Otherwise, you would have > people add / remove things from a normal set and break the mask > intent. Using the conventional view of what a "set" is, the point is to allow you to mask, say, kde7 using a single line, and then define what kde7 is using a set. Then the user can unmask kde7 without having to copy a big, potentially changing list of packages out of package.mask. Now, if you're viewing a set as being a metapackage rather than a list of specs, this doesn't apply. But then why have sets at all if they're just a metapackage? -- Ciaran McCreesh
signature.asc
Description: PGP signature
