On 21/03/2012 13:41, Shawn Walker wrote: > 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
So this would be an 'avoid' list. I think I'll add an RFE for this one. > > * 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) Which is what I started out implementing... :) > > * uninstall; packages to explicitly remove after all other package > operations (you already have this I believe) Yep, have this. > >> It sounds like we need two different things here - just like pkg(1) has. > > Three, potentially. OK, I meant 2 in the cases of 'avoid' and 'reject' > >> 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). Yep, that's fine. > >> 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. My fault, the names in the <software> tags are just arbitrary strings, probably should have picked something else... Sorry for the confusion on that... What this meant to show, was that in the second <software></software> set there would be no reject list active. Thanks, Darren. _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
