On 03/21/12 06:22, Darren Kenny wrote:
On 20/03/2012 22:23, Shawn Walker wrote:
(--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?
That depends on what functionality you're trying to expose to the user.
What I'd suggest is that you expose three different bits of functionality:
* list of packages to avoid (general image configuration to be set
before any packages are installed) -- these only affect group
dependencies
* reject on a per-operation basis (allow the user to specify packages
that will be removed / not be allowed during each install or update
operation)
* uninstall; packages to explicitly remove after all other package
operations (you already have this I believe)
It sounds like we need two different things here - just like pkg(1) has.
Three, potentially.
So maybe we need to consider another RFE to add the 'pkg avoid'
functionality to the IPS transfer section?
Yes, see above.
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?
Correct.
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...
Be aware that versions are ignored for --reject (reject_list in the API).
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>
The with_reject, no_reject is confusing. In general, I'd suggest
avoiding the "no" prefix; it's awkward terminology at best.
-Shawn
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
