| 1 |
Kevin F. Quinn wrote: |
| 2 |
> On Tue, 29 Aug 2006 07:57:43 -0400 |
| 3 |
> Alec Warner <antarus@g.o> wrote: |
| 4 |
> |
| 5 |
>> So I have implemented merging of sets (more or less) in a local |
| 6 |
>> portage branch. |
| 7 |
> |
| 8 |
> Could you elaborate how the implementation of sets would differ from: |
| 9 |
> |
| 10 |
> # emerge $(cat /var/lib/portage/myset) |
| 11 |
> |
| 12 |
> where /var/lib/portage/myset is a file containing a list of atoms? |
| 13 |
> That would help in thinking what the behaviour could be. |
| 14 |
> |
| 15 |
> I'm thinking that perhaps you do everything up to but not including |
| 16 |
> qmerge for all packages then do the qmerge phase for the set in one go, |
| 17 |
> provided they all got to install ok. It might be useful to try to move |
| 18 |
> all actions that might fail during qmerge to the end of the install |
| 19 |
> phase (I'm thinking things like collision-detection, qa checks), so |
| 20 |
> that the only reason qmerge on the set would fail is lack of disk space. |
| 21 |
> |
| 22 |
|
| 23 |
one word, no ;) This is designed (for now) to be rather non-intrusive. |
| 24 |
Here you are talking about major changes with code and behavior. At |
| 25 |
this point you could implement all of that for any number of packages |
| 26 |
(not just sets). |
| 27 |
|
| 28 |
> Obviously that's simplifying somewhat - if there are build-time DEPEND |
| 29 |
> relationships between elements of the set, the set has to be broken |
| 30 |
> down into sub-sets that don't have such internal dependencies. However |
| 31 |
> I can't think of much else you would do with sets that the $(cat |
| 32 |
> <file>) approach doesn't already supply. Alternatively you could |
| 33 |
> require that sets must not have such internal dependencies. |
| 34 |
|
| 35 |
Dynamic sets (World,All,GLSA,System), these are not 'static' in the |
| 36 |
sense of normal files. |
| 37 |
|
| 38 |
> |
| 39 |
>> However there are some use cases for which the |
| 40 |
>> appopriate action is ambiguous. |
| 41 |
>> |
| 42 |
>> Use Case #1: |
| 43 |
>> Set1 = { postfix, gentoolkit, lsof, bind-utils, vixie-cron } |
| 44 |
>> |
| 45 |
>> A set of standard tools to be on a machine. Assume a new install (ie |
| 46 |
>> none of the packages in Set1 are installed). Is it an error if one of |
| 47 |
>> the packages in the set is masked or unavailable? In this case I |
| 48 |
>> would say yes; if you instead just skip the masked package (say |
| 49 |
>> postfix in this case because it's convenient ) vixie-cron will pull |
| 50 |
>> ssmtp instead of postfix. |
| 51 |
>> |
| 52 |
>> Of course this will also occur if postfix is after vixie-cron in the |
| 53 |
>> set; but for our purposes we will assume the administrator put them in |
| 54 |
>> this order such that postfix will get pulled in. |
| 55 |
>> |
| 56 |
>> One could also say that the user should have used emerge -pv set1 and |
| 57 |
>> noticed that ssmtp is being pulled in instead of postfix. |
| 58 |
>> |
| 59 |
>> Use Case #2: |
| 60 |
>> |
| 61 |
>> Set1 = cat /var/lib/portage/world (the world set) |
| 62 |
>> |
| 63 |
>> Assume the world file has 100 packages in it, two which are masked, |
| 64 |
>> and three of which there are no ebuilds in the tree for. If missing |
| 65 |
>> packages cause an error (which in use case 1 they should imho) then |
| 66 |
>> the user cannot update world without unmasking things properly. The |
| 67 |
>> packages for which ebuilds are missing in the tree is in fact a |
| 68 |
>> portage bug(I think), and will probably need to be fixed. |
| 69 |
> |
| 70 |
> For the initial merge case then an error before anything is merged is |
| 71 |
> good. For an upgrade merge, a warning would be more appropriate |
| 72 |
> (perhaps becoming an error with FEATURES=stricter or similar). |
| 73 |
> |
| 74 |
>> Other use cases for sets would be appreciated, as far as behavior. It |
| 75 |
>> would probably be best to provide some sort of switch. |
| 76 |
> |
| 77 |
> The most obvious use is to have a related group of packages that may |
| 78 |
> otherwise include a virtual, making the choice of that virtual explicit |
| 79 |
> (like your cron example above). |
| 80 |
> |
| 81 |
> Other sets would be simply groups of packages that make functional |
| 82 |
> sense together, where perhaps one package might make little sense |
| 83 |
> without others in the set. For example: |
| 84 |
> |
| 85 |
> sylpheed-kev = ( sylpheed-claws sylpheed-claws-mailmbox \ |
| 86 |
> sylpheed-claws-smime sylpheed-claws-rssyl sylpheed-claws-smime \ |
| 87 |
> sylpheed-claws-vcalendar) |
| 88 |
> |
| 89 |
> toolchain4 = ( \ |
| 90 |
> ~sys-devel/gcc-4.1.1 \ |
| 91 |
> ~sys-devel/binutils-2.16.1 \ |
| 92 |
> ~sys-libs/glibc-2.4 ) |
| 93 |
> |
| 94 |
> Are you considering allowing sets to contain other sets? Then world |
| 95 |
> would contain the names of sets, not just CPs. |
| 96 |
|
| 97 |
At this point, no. |
| 98 |
|
| 99 |
> |
| 100 |
>> Unmerging sets is also a fun one, I'm not sure if it's entirely |
| 101 |
>> appropriate yet. |
| 102 |
> |
| 103 |
> Would it do anything more than: |
| 104 |
> |
| 105 |
> # emerge -C $(cat /var/lib/portage/myset) |
| 106 |
> |
| 107 |
> Perhaps it would unmerge any packages merged as dependencies of the |
| 108 |
> set that are no longer dependencies of anything else currently |
| 109 |
> installed - but I think that's better handled separately. |
| 110 |
|
| 111 |
I don't want to differ from normal portage behavior in this regard. |
| 112 |
When portage can do this, sets should as well, if portage doesn't for |
| 113 |
normal packages, I don't want to special case sets. |
| 114 |
|
| 115 |
> |
| 116 |
> Ah; it occurs to me that unmerging a set should only unmerge elements |
| 117 |
> of the set that are not part of any other installed set (including |
| 118 |
> world). So behaviour is less like 'emerge $(cat <set>)' and more like |
| 119 |
> emerge sets/<set> where <sets>/set/set-V.ebuild is like a meta-ebuild. |
| 120 |
> |
| 121 |
|
| 122 |
This is an interseting idea. But then not all sets are equal; world, |
| 123 |
system, and the "All" set change fairly often. Plus everything installed |
| 124 |
is in "All" so you would want to ignore that set, as well as probably |
| 125 |
the world set. |
| 126 |
-- |
| 127 |
gentoo-dev@g.o mailing list |
Archives