On 20/03/2012 22:23, Shawn Walker wrote:
> On 03/20/12 14:18, Ethan Quach wrote:
>>
>>
>> On 03/20/12 10:51, Shawn Walker wrote:
>>> On 03/20/12 09:50, Ethan Quach wrote:
SNIP
>>>
>>> 'avoid' has a different meaning than 'reject'; 'avoid' means "if
>>> possible, don't install this package" and is really only meaningful in
>>> the context of group dependencies. Whereas reject says "this package
>>> can *NOT* be installed". Think of 'avoid' as package "defriend" 8)
>>>
>>> 'reject' was chosen because it means both "do not install" and "remove
>>> if it is already installed" and because 'exclude' is a special type of
>>> dependency so we didn't want to add to the confusion.
>>
>> Sure, if that works better, then sounds fine to me.
>>
>> We glom all packages listed by the user to be installed in one single
>> transaction so I figured setting up the "avoid" list on the image prior
>> to the install transaction would result in the same thing.
>
> Setting up the "avoid" list (i.e. what "pkg avoid" does) before
> operations is the right answer. It will prevent the installation of
> matching group dependencies and it will automatically keep optional
> group dependencies from coming back in the future on upgrade, etc.
>
>> Question. If we did end up having multiple install transactions (e.g.
>> some additional hidden install/uninstall in a ICT somewhere), would
>> those subsequent transactions need to be called with the same reject
>> packages to ensure they're not brought in .... in case the first install
>> transaction didn't actually have to reject said packages? In other
>> words, if the first install transaction didn't actually have to reject
>> said packages, do they get stored on a list so that subsequent install
>> transactions also reject them?
>
> (--reject)s are not persistent; they're only valid for the duration of
> an operation. We've talked about implementing a persistent rejection
> mechanism, but there a lot of pitfalls.
>
> If you want to add things to the "never install these list", you must
> specify those for every package operation you plan.
>
Do we want them to be persistent, or only set during the install phase?
It sounds like we need two different things here - just like pkg(1) has.
So maybe we need to consider another RFE to add the 'pkg avoid'
functionality to the IPS transfer section?
As for another ICT based install possibly pulling in a package, surely that
would only happen if that package depended upon a previously rejected
package, or am I mistaken?
Regardless, I'm not sure that I want to add all rejected packages to a
global list, since it may be the desire of the user to reject the package
from the solaris publisher, but to add it from another publisher...
Right now, I'm just gathering the list of packages as in a single
<software> node set, another <software> element will not use that same list
of rejected packages from another, e.g.:
<software name="with_reject">
<software_data action="reject>
<name>rejected/pkg</name>
</software_data>
<software_data action"install">
<!-- reject list is used here -->
</software_data>
</software>
<software name="no_reject>
<software_data action="install>
<!-- there is no reject list here -->
</software>
</software>
Thanks,
Darren.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
