Tom Mueller wrote:
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.,
Yes.
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
Yes.
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.
I'm personally fine with modifying the file action to not require a path
attribute, but that does mean that file would no longer have a key
attribute. I guess that means that the rule would be that you could
have one file per hash instead.
The once nice advantage of that is that it solves your storage and
caching problem. That is, if you request a file from the transport
system, it will be cached automatically in /var/pkg/download. That also
means that the same icon, if it does have a path attribute, won't have
to be retrieved again during install.
It looks like we need to expose retrieving file data in the api somehow.
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.
See above.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
