Shawn Walker wrote:
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.
Are you assuming that there would be a corresponding file action for the
file? i.e.,
set name=pkg.icon.24x24 value=10239491234...
file 10239491234... group=... mode=... owner=... path=?
And this is why pkgrecv doesn't need to know about the hash? I wasn't
assuming there would be a file action for the file because there may not
be a good path value to pick? The "publishing changes" would provide
for being able to upload the file with the set action. But maybe that
isn't what was meant by publishing changes. Someone (Bart?) suggested
maybe modifying the file action to not require a path for just this
purpose.
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.
Not installing or caching the icon for installed packages means that the
GUI has a problem when it tries to browse the installed packages while
not connected to the network. So I'm assuming that for an installed
package, you want the icon cached or installed somewhere.
Tom
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,
begin:vcard
fn:Tom Mueller
n:Mueller;Tom
org:Sun Microsystems, Inc.;Update Center Software
adr:;;21915 Hillandale Dr;Elkhorn;NE;68022;USA
email;internet:[email protected]
title:Senior Staff Engineer
tel;work:877-250-4011
tel;fax:877-250-4011
tel;home:402-916-9943
x-mozilla-html:TRUE
version:2.1
end:vcard
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
