Zac Medico wrote: > Steve Long wrote: >> Zac Medico wrote: >>> Rémi Cardona wrote: >>>> As one of the maintainers of the gnome-base/gnome meta, I fail to see >>>> the usefulness of such a change. We have yet to ask users to rebuild >>>> "gnome" completely. Do you have any specific use cases (maybe coming >>>> from the KDE herd, since you used the kde meta as an example) ? >>>> >>> Over the course of the discussion I've revised the idea so that it >>> essentially represents a way to define a package set, without any >>> changes to existing behavior. What will change is that we will have >>> a new way to define package sets, based on ebuilds. >> >> Makes sense to me, though not sure you need the mapping file. I'm >> perfectly happy about emerge -uDN @kde-meta say, updating all kde-meta >> packages I might have installed; I take it that after emerge kde-meta to >> install, and then removing some of the packages, the user could continue >> to reference the set for upgrade, without portage reinstalling those? > > That would be a set subtraction operation, so the user would use a > configuration file to configure the set so that certain unwanted > atoms are automatically subtracted out. Alternatively, we could > implement a syntax extension for "optional atoms" that are only > pulled into the dependency graph if they happen to be installed already. > It would be nice to address it; wrt people installing a meta which will define a set, it'd make it easier to maintain (a box) if the set syntax referred to whatever was installed, whereas emerging the package would install all its deps as a standard virtual does (in the default setting.)
Integrating seems like a good idea, wrt to the USE settings you discussed in the other thread. There is already a framework in place to model all that, and more, so might as well use it. (I'd vote for allowing as much flexibility as the ebuild author wants to specify.)
