Tom Mueller (pkg-discuss) wrote:
Danek,
Can you please respond to the reasons that were given previously in this
thread as to why
using existing actions, namely the set action will not work? If
existing actions will work, then
how do we solve these problems:
1. Assuming that there is a set action with a hash code for the value,
how does pkgrecv know
that this value is to be interpreted as an identifier for a file? Does
the set action have to be
tagged with some special tag? If so, how is this different from adding
a separate action? Adding
a special tag to the set action would seem to be overloading the meaning
of a set action.
pgkrecv/pkgsend doesn't need to know about the hash. Adding custom tags
to set is exactly what set is for; to provide custom package metadata.
2. Again assuming that a set action is used for icons and other
file-based package meta data,
where would the meta data file (the icon for example) be cached in the
image? Specifially,
how would the set action know that there is data (a file) to cache, and
what name would
it use to store that data. Would another tag be defined for this?
(Bart did respond to this
earlier by saying that the client could cache the data where ever it
wants, but the problem with
this is that different clients would not have a consistent way of
accessing the cached data.)
Different clients aren't likely to need a consistent way of accessing
the cached data. For all practical purposes, we only have one GUI
packaging client on each platform, so shared access isn't necessary.
Although it doesn't really matter, since as proposed, you would have to
add file data to the package, and that requires the 'path' attribute.
So, you would know where the icon is because of the path.
For a lot of software packages, this probably won't be an issue since
the icon is already likely installed. But it does mean that you won't
be able to have files that aren't installed, but are available as extra
metadata for the client to consume.
By following this logic of using a set action for an icon, the same
argument could be made that
we really did not need a license action either. We could have just had:
Not quite. Unlike the proposed icon/info action, license actions
actually can affect the installation of software (by preventing it), and
require the packaging system to record acceptance of licenses in the
operational history of the image.
With all that said, the one question left is given a hash on a set
action, where and how do you store the file data?
The issue of wanting to the know the hash at publication time is easy
enough to solve; we can work out those specifics.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
