On 02/20/12 13:10, Chris Quenelle wrote:
I like the idea of skipping the real version if the human-readable
alternative is available. I'm not sure about adding attributes...
If your plan is to make the incorporation package *look* like a proxy
package for an entire product, then do we really believe it effectively
*acts* as a complete proxy package? If I uninstall the incorporation package,
(thinking that it acts on behalf of the entire product) then wouldn't I
expect to have the entire product uninstalled?
eg: pkg uninstall group/system/solaris-desktop
No, this is not about making it look like a proxy package. This is
solely about how we present changes to packaging during install and update.
What you're talking about is orthogonal to what is being discussed here.
That is, it can happen completely separately with no real impact on
this proposal.
I have an action item to file an IPS RFE that requests such a
"proxy package" be implemented so that we can use it to install/uninstall
the entire Solaris Studio product in a way that's more intuitive than
the existing empty packages and incorporation packages. The specific
weirdness is the uninstall behavior. I'd like to see this problem solved,
and I don't think it helps to make the incorporation package look
more like a (proxy/product) package.
Would it achieve your immediate goals to just modify the
human-readable attributes for the Solaris incorporations so
they refer directly to the product instead of referring to their own
incorporation-nature?
No, for reasons already stated. I don't want to force the textual
attributes we currently use for our incorporations to be re-purposed for
update summaries. The set of attributes we currently have rightfully
describe the package instead of the product or subsystem they represent.
If you're still looking at adding new attributes, here's some thoughts
on how to work out the details for the new attributes.
I think pkg.product-name and pkg.product-summary might be a separate
feature with a bigger scope than what you're doing here. It would be nice to
see the following spelled out for them:
1. when they are allowed (by pkg and by pkglint)?
Always allowed.
2. when should the end user expect to see them in Oracle packages
Is this only expected to be used for incorporations?
We don't really have "types of packages" -- it's only by convention that
some of our package are referred to as incorporations.
As for a user, they shouldn't "expect to see" these at all; their use
should be largely invisible to the user.
I expect a very limited set of usage for this metadata.
3. when is the end user expected to generate them for their own packages?
Not currently expected to.
4. will it supercede other forms of package description in GUI and cmd line?
No. This is currently only intended for usage in an update summary
scenario.
4. The Studio packages have a "require-style" pseudo-package, so hopefully
we would be able to take advantage of these new attributes.
Unbundled products require additional consideration. Currently, the
addition of pkg.product-name would be sufficient to have change summary
information displayed.
However, Studio should be using an incorporation, which is something I
know has already been discussed.
5. It would be nice to spell out the basics of how this attribute is expected
to be used in the packagemanager gui.
Hopefully the GUI tools will display the information the same way the
CLI does when implemented at a later date. They should not use the
information in any other fashion.
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
