Edward Pilatowicz wrote:
On Tue, Jul 28, 2009 at 04:35:31PM -0500, Shawn Walker wrote:
- catalog.dependency.C
This catalog part contains the FMRIs of the packages that the
repository contains, any 'depend' actions, and any 'set' actions
for facets or variants. This information is intended to be used
during dependency calculation by install, uninstall, etc. It is
anticipated that package size summary information, and actions
for set pkg.renamed and pkg.obsolete will be stored in this part
as well when they become available. Note that since this infor-
mation is common to all locales, this part of the catalog is
only offered for the 'C' locale. An example of its contents is
shown below:
{
"opensolaris.org":{
"SUNWdvdrw":[
{
"version":"5.21.4.10.8,5.11-0.108:20090218T042840Z",
"actions":[
"set name=variant.zone value=global value=nonglobal",
"set name=variant.arch value=sparc value=i386",
hm. this example seems invalid to me. afaik, no packages actually have
a package variant.zone setting, and if they did i don't think it would
work correctly. there is special handling for the package variant.arch
setting, but not for the variant.zone setting. variant.zone are only
applicable to individual actions.
They do; this came from the actual manifest data:
http://pkg.opensolaris.org/dev/manifest/0/[email protected],5.11-0.108:20090218T042840Z
I think they're "informational only" at this point, but you'd have to
ask Bart.
... a warning will be provided to the client that there
may be something wrong with the repository (packages may be
missing, etc.).
there are multiple conditions where you propose to alert the client that
there may be something wrong with the repo. i don't think that this is
all that helpfull of an error message.
There are really only two options: abort or continue. We've run into
problems on multiple (but thankfully rare) occasions where repository
changes caused a client failure, so the consensus so far has been to
attempt to correct the situation, warn the user, and continue.
Remember that these cases should be the exception, and not the rule.
The general idea is to suggest that the user contact the repository
maintainer for assistance.
it seems to me that in this case instead of warning the client user that
the repo could be broken, it'd be best if we simply tell the client user
that the repo has been rebuilt.
We don't know if the repository has been rebuilt. It could have been
rebuilt, or it could be somehow broken and not sending correct
responses, or it could have been restored to an earlier version that
doesn't contain packages they're currently using.
then, before just downloading the newest repo catalog the client could
to scan it's existing catalog/pkg info and compare it to what's
available in the rebuilt repo. if nothing has changed for installed
packages then there is no problem and the client can download the latest
catalogs and continue the current operation.
For incremental updates, we purposefully avoid downloading the catalog
'parts', so that won't work. Remember also that catalogs will be signed
in the near future, so there is the cryptographic integrity to consider
as well. We also have no way of knowing if a repository was 'rebuilt'
vs. some other event.
but if metadata has changed for packages that are already installed,
then the *client* is actually broken wrt the current repo, and we should
tell the user that. we could also tell them specifically which packages
are broken and refuse to update the local catalogs until the issue is
resolved (perhaps by having the user uninstall the broken packages, or
by contacting their repo admin to tell them that they've broken package
foobar, etc).
The consensus so far has been to warn the user, correct if possible, and
drive on. Currently we tend to just 'throw up our hands' and fail
instead of attempting to continue.
Also, it's intentional that packages might be removed from the catalog,
and so we can't assume that because a package or metadata is missing
from it that the package is broken (think toxic packages removed for
legal reasons, etc.). In short, the system is designed and intended to
allow for packages that are marked as being from a specific publisher,
but are not in any catalog.
I'm in the process of adding a section to each file to account for
digest and cryptographic data which should further address verification
issues.
Thanks for the feedback,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
