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 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? 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)? 2. when should the end user expect to see them in Oracle packages Is this only expected to be used for incorporations? 3. when is the end user expected to generate them for their own packages? 4. will it supercede other forms of package description in GUI and cmd line? 4. The Studio packages have a "require-style" pseudo-package, so hopefully we would be able to take advantage of these new attributes. 5. It would be nice to spell out the basics of how this attribute is expected to be used in the packagemanager gui. ------- On Monday February 20, at 10:58AM, Shawn Walker wrote: > On 01/12/12 16:28, Shawn Walker wrote: >> On 12/22/11 17:46, Shawn Walker wrote: >>> This is a proposal (primarily) to change the output of pkg(1) when -v is >>> not used for package operations. When -v is not used, an 'update >>> summary' would be displayed instead at the install-hold level. It also >>> attempts to improve messaging in the 'No updates available' case. >> ... > > A related problem that I'd also like to solve with this is to be able to use > better "rollup names" for the update summaries. The first draft of this > proposal improved on versions by leveraging the pkg.human-version attribute > (if present), but the names of what we're updating is essentially meaningless > to the user in many cases. > > Incorporations were chosen as the rollup-level for updates as they > (approximately) represent "products" within the greater Solaris ecosystem > (and conveniently, boundaries of change of items likely to depend on each > other). > > However, the pkg.summary and pkg.description for the incorporation packages > (such as 'entire', 'osnet-incorporation', etc.) necessarily describe the > *incorporation package* itself -- not the "product" (aka consolidation) they > represent. For example, entire's pkg.summary is "Incorporation to lock all > system packages to the same build". But from a product perspective (when > updating / installing), it's "Oracle Solaris". > > If we had additional metadata to describe the products they represent, then > we could further improve the update summaries provided. Suggested fields are > pkg.product-name and pkg.product-summary. I'd also like to suggest we have > pkg.vendor to easily identify the company that produced the package easily > (e.g. set name=pkg.vendor value=Oracle). > > In addition, I believe the update summary proposed so far can be further > simplified by focusing on the fact that it is not intended to provide the > level of detail that using -v does. With that in mind, some information can > be omitted if pkg.human-version and/or pkg.product-name are provided further > simplifying the output and substantially improving readability. > > Specifically, if pkg.human-version is provided, then the actual version can > be omitted from the summary. Likewise, if the pkg.product-name is provided, > then the actual package name can be omitted from the summary. > > For example, these: > > PACKAGE CHANGE SUMMARY > solaris > entire > Installed: FCS Build 2 (0.5.11-0.175.0.0.0.2.0) > Latest: SRU 2 Build 3 (0.5.11-0.175.0.2.0.3.0) > Proposed: SRU 1 Build 4 (0.5.11-0.175.0.1.0.4.0) > > > PACKAGE CHANGE SUMMARY > solaris > entire > Installed: FCS Build 2 (0.5.11-0.175.0.0.0.2.0) > Proposed (Latest): SRU 2 Build 3 (0.5.11-0.175.0.2.0.3.0) > > > ...can be simplified to (assuming only one publisher offers the package): > > > PACKAGE CHANGE SUMMARY > Oracle Solaris > Package: entire > Installed: FCS Build 2 > Latest: SRU 2 Build 3 > Proposed: SRU 1 Build 4 > > > PACKAGE CHANGE SUMMARY > Oracle Solaris > Package: entire > Installed: FCS Build 2 > Proposed (Latest): SRU 2 Build 3 > > > ...if more than one publisher offers the package, the publisher name would be > shown in parentheses: > > PACKAGE CHANGE SUMMARY > Oracle Solaris > Package: entire (solaris) > Installed: FCS Build 2 > Latest: SRU 2 Build 3 > Proposed: SRU 1 Build 4 > > ...if the publisher of the package is changing as part of the operation: > > PACKAGE CHANGE SUMMARY > Oracle Solaris > Package: entire (solaris -> wos-nightly) > Installed: FCS Build 2 > Latest: SRU 2 Build 3 > Proposed: SRU 1 Build 4 > > > However, if the summary is being shown as the result of a failure to find > updates (due to constraints, as an example) or if the user specified a > version explicitly on the command line, full version information would be > shown as below: > > PACKAGE CHANGE SUMMARY > Oracle Solaris > Package: entire (solaris) > Installed: FCS Build 2 (0.5.11-0.175.0.0.0.2.0) > Latest: SRU 2 Build 3 (0.5.11-0.175.0.2.0.3.0) > > -Shawn > _______________________________________________ > pkg-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/pkg-discuss _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
