Re: [gentoo-dev] Portage Sets

[Kevin F. Quinn]

On Tue, 29 Aug 2006 07:57:43 -0400
Alec Warner <antarus@g.o> wrote:

> So I have implemented merging of sets (more or less) in a local
> portage branch.

Could you elaborate how the implementation of sets would differ from:

# emerge $(cat /var/lib/portage/myset)

where /var/lib/portage/myset is a file containing a list of atoms?
That would help in thinking what the behaviour could be.

I'm thinking that perhaps you do everything up to but not including
qmerge for all packages then do the qmerge phase for the set in one go,
provided they all got to install ok.  It might be useful to try to move
all actions that might fail during qmerge to the end of the install
phase (I'm thinking things like collision-detection, qa checks), so
that the only reason qmerge on the set would fail is lack of disk space.

Obviously that's simplifying somewhat - if there are build-time DEPEND
relationships between elements of the set, the set has to be broken
down into sub-sets that don't have such internal dependencies.  However
I can't think of much else you would do with sets that the $(cat
<file>) approach doesn't already supply.  Alternatively you could
require that sets must not have such internal dependencies.

>  However there are some use cases for which the
> appopriate action is ambiguous.
>
> Use Case #1:
> Set1 = { postfix, gentoolkit, lsof, bind-utils, vixie-cron }
>
> A set of standard tools to be on a machine.  Assume a new install (ie
> none of the packages in Set1 are installed).  Is it an error if one of
> the packages in the set is masked or unavailable?  In this case I
> would say yes; if you instead just skip the masked package (say
> postfix in this case because it's convenient ) vixie-cron will pull
> ssmtp instead of postfix.
>
> Of course this will also occur if postfix is after vixie-cron in the
> set; but for our purposes we will assume the administrator put them in
> this order such that postfix will get pulled in.
>
> One could also say that the user should have used emerge -pv set1 and
> noticed that ssmtp is being pulled in instead of postfix.
>
> Use Case #2:
>
> Set1 = cat /var/lib/portage/world (the world set)
>
> Assume the world file has 100 packages in it, two which are masked,
> and three of which there are no ebuilds in the tree for.  If missing
> packages cause an error (which in use case 1 they should imho) then
> the user cannot update world without unmasking things properly.  The
> packages for which ebuilds are missing in the tree is in fact a
> portage bug(I think), and will probably need to be fixed.

For the initial merge case then an error before anything is merged is
good.  For an upgrade merge, a warning would be more appropriate
(perhaps becoming an error with FEATURES=stricter or similar).

> Other use cases for sets would be appreciated, as far as behavior.  It
> would probably be best to provide some sort of switch.

The most obvious use is to have a related group of packages that may
otherwise include a virtual, making the choice of that virtual explicit
(like your cron example above).

Other sets would be simply groups of packages that make functional
sense together, where perhaps one package might make little sense
without others in the set.  For example:

sylpheed-kev = ( sylpheed-claws sylpheed-claws-mailmbox \
	sylpheed-claws-smime sylpheed-claws-rssyl sylpheed-claws-smime \
	sylpheed-claws-vcalendar)

toolchain4 = ( \
	~sys-devel/gcc-4.1.1 \
	~sys-devel/binutils-2.16.1 \
	~sys-libs/glibc-2.4 )

Are you considering allowing sets to contain other sets?  Then world
would contain the names of sets, not just CPs.

> Unmerging sets is also a fun one, I'm not sure if it's entirely
> appropriate yet.

Would it do anything more than:

# emerge -C $(cat /var/lib/portage/myset)

Perhaps it would unmerge any packages merged as dependencies of the
set that are no longer dependencies of anything else currently
installed - but I think that's better handled separately.

Ah; it occurs to me that unmerging a set should only unmerge elements
of the set that are not part of any other installed set (including
world).  So behaviour is less like 'emerge $(cat <set>)' and more like
emerge sets/<set> where <sets>/set/set-V.ebuild is like a meta-ebuild.

-- 
Kevin F. Quinn