On 03/21/12 06:22, Darren Kenny wrote:
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>
My only tiff here is the implied implementation. I not sure I agree
that "reject" should be an action type. From a logical standpoint, it
would apply to some other peer elements, but not others. To me, that's
confusing; and as a general solution to handle options, doesn't scale.
Thinking out loud, could we implement this by introducing an <option>
element (like the one defined in target.dtd.1) as a subelement of
<software_data type="install"> ? i.e.
<software name="foo_IPS">
<software_data action="install">
<name>pkg:/entire@latest</name>
<name>pkg:/group/system/solaris-large-server</name>
<option name="reject" value="pkg_to_reject"/>
<option name="reject" value="another_pkg_to_reject"/>
</software_data>
</software>
The transfer/ips module would semantically take options we explicitly
want, and ignore and not pass through all others (even ones that might
be valid to pkg.) We'd perhaps just log what we're ignoring. The big
benefit with this in that we can later decide to support any other
options we might want (perhaps new ones) by updating the installer
transfer/ips implementation, but the dtd doesn't have to change. The
downside is loose syntax, but I personally can live with that.
Thoughts?
-ethan
Thanks,
Darren.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
