>> >>>> >>>> The solution in use case 3 tries to infer format based on the >>>> attributes specified, and misses existing and future options. For >>>> example, it's possible to install SVR4 packages from an http URL, >>>> and IPS will have an on-disk format in the future. I strongly >>>> recommend making declaration of package type explicit, if that's >>>> necessary, or have it automatically resolved by your solution based >>>> on a recognition of the location's format (which may be relatively >>>> simple). >>> Good point. Better not to assume a certain format or location type >>> for different kinds of packages. I think being explicit about the >>> type of package is better than resolving it automatically for the >>> following reasons: >>> - It makes the package type explicit in the manifest, with no extra >>> effort on the user's part. (Instead of "package" elements, we can >>> have "IPS", "legacy" and "DU" elements to call out the specific types.) >>> - It is more maintainable, since if some new format of a package is >>> introduced, the installers won't have to be updated to recognize them. >>> >>> Additionally, it is simpler for us to implement at the outset. >> >> I would not use "package" elements. Perhaps call it a "driver_bundle" >> or something of the sort with an additional "type" attribute. This >> avoids further overloading the package term, and limits the amount of >> change to the schema required for additional types, should any future >> ones be needed. > I changed "package" elements to "IPS", "legacy" and "DU" elements.
That would still leave the problem of needing a schema update to add additional types, though, wouldn't it? I think it would be preferable to not need that. >> >>> >>> See sample below. >>>> You mention a compatibility requirement for DU packages, but I'm >>>> unclear how you expect to make that determination. >>> Packages in a DU image are nestled under a subdirectory with the >>> version in its name. On NV it is sol_211, for 5.11. That version is >>> checked when a DU image is installed. This version is how I would >>> check compatibility. (Reference: in onnv, check >>> usr/src/cmd/itutools/updatemedia.ksh and pkg2du.ksh) >> >> For our purposes here, that's potentially excessively restrictive; >> many S10 drivers will run just fine on Solaris next. At most I'd >> expect a warning from such a check. > OK. But there's also the case of a single DU image containing multiple > OS versions of the same driver. If we're going to accept OS versions > other than our own, we can start with our own and work our way down > until we find one with the driver we want, to get the latest version the > image has of that driver. > > "Working our way down" is a maintainable solution as long as there is an > ordered pattern to the versions from here forward. (For example, if the > current version is "a" and the next version is "b", we can start with > the current letter and "decrement" in the future without having to > change the code.) > > Does this sound reasonable? > I"m not sure how regular the versioning used with these is - are there guidelines in the developer docs for DU's? Anyway, I think looking at a reasonable sample set would be necessary to decide if such a heuristic is going to work. Dave
