On 03/20/12 10:51, Shawn Walker wrote:
On 03/20/12 09:50, Ethan Quach wrote:
On 03/20/12 08:14, Darren Kenny wrote:
On 20/03/2012 14:50, Dave Miner wrote:
On 03/20/12 10:42, Darren Kenny wrote:
On Tue Mar 20 14:14:33 2012, Dave Miner wrote:
On 03/20/12 04:10, Darren Kenny wrote:
Hi Shawn,
On 16/03/2012 20:12, Shawn Walker wrote:
On 03/16/12 05:38, Darren Kenny wrote:
Hi,
Could I please get a code review for the following bug and RFE:
7152537 AI fails to install packages with licenses using
must-display=true
and not must-accept=true
7145997 noinstall element should be implemented as reject for
pkg transfer
It may be too late to change this, but 'noinstall' doesn't
exactly roll
off the tongue. Why was this term used instead of 'reject'?
At the time that the DTD was first envisaged, the term 'reject'
wasn't in
use by pkg.
Other than that, I've no idea why noinstall was used originally.
We could look at a bug to change it at a later date if the DTD is
being
reved anyway - but otherwise we are pretty much stuck with it,
even revving
it could actually present reason for maintaining support for both
names...
Since we've not previously implemented this for any of the transfer
modes, I think it could be changed without concern for
compatibility.
"Reject" isn't a term that is commonly used with other modes such as
cpio, but then neither is "noinstall". I'd probably opt to change it
based on the assumption that most of the uses that end-users will
have
would be pkg-style transfers, though I'm planning to implement it
for
cpio internally at least (7123561).
OK - so you're saying it would be OK to change this without
revving the
DTD? Based on no existing users that makes sense.
Right.
So could I propose then that we use the term "exclude" - this would
seem to
fit the pkg and CPIO usages better?
I'd be more inclined to ensure we had terminology that aligned with
pkg
in this case. I could see having both as synonyms, I guess, but I'm
not
sure it's worth the trouble.
Ok, so "reject" it is then...
Should it be reject or avoid? The latter has its own pkg subcommand
which would seem to make it more aligned with our install and uninstall
action types for processing ips packages.
'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.
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?
thanks,
-ethan
-Shawn
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
