Tom Mueller (pkg-discuss) wrote:
The problem isn't with the client API. It's with publishing. How is one
at build time supposed to generate a pkgsend request that looks like this:
pkgsend add set name="pkg.icon" value="130989AB341248..."
where the value is the SHA1 value for some file. It's much easier to
generate:
pkgsend add set name="pkg.icon" value="images/myicon.gif"
The client can look at the manifest to see the SHA1 hashval, and then
determine whether it has to be downloaded from that.
True, without special logic for the pkg.icon attribute (obviously not
desirable), it would not be trivial at the moment. But something could
be added to make this practical.
The problem with setting "images/myicon.gif" is the performance cost for
discovering the hash name. To get the actual icon's hash name:
* the manifest for the package will have to be loaded
* the manifest for the package will have to be parsed
* all of the file actions will have to be searched (of which there could
be many) for a matching entry
* when the match is found, the SHA-1 name can be returned
...that's quite a bit of I/O just to get a hash name, especially for
large manifests (and remember that our manifests are "multi-variant" now).
The three possible solutions I can think of at the moment are (in order
of preference):
1) change pkgsend to output the hash name when performing "add file"
(the publishing api will need to calculate the hash name anyway for bug
391 [1])
2) add special logic for the pkg.icon attribute to move the expense of
the lookup to publication time
3) perform the relatively expensive lookup mentioned above
Option 1 seems the cheapest, and may have other benefits as well.
Cheers,
--
Shawn Walker
[1] http://defect.opensolaris.org/bz/show_bug.cgi?id=391
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
