Kevin F. Quinn wrote:
> On Tue, 29 Aug 2006 07:57:43 -0400
> Alec Warner <[EMAIL PROTECTED]> 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.
>
one word, no ;) This is designed (for now) to be rather non-intrusive.
Here you are talking about major changes with code and behavior. At
this point you could implement all of that for any number of packages
(not just sets).
> 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.
Dynamic sets (World,All,GLSA,System), these are not 'static' in the
sense of normal files.
>
>> 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.
At this point, no.
>
>> 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.
I don't want to differ from normal portage behavior in this regard.
When portage can do this, sets should as well, if portage doesn't for
normal packages, I don't want to special case sets.
>
> 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.
>
This is an interseting idea. But then not all sets are equal; world,
system, and the "All" set change fairly often. Plus everything installed
is in "All" so you would want to ignore that set, as well as probably
the world set.
--
[email protected] mailing list
