Edward Pilatowicz wrote:
On Wed, Jul 29, 2009 at 09:10:02PM -0500, Shawn Walker wrote:
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.
yes. but these conditions will happen. and when one of these instances
happens the user probably won't contact the repo maintainer because the
command emitted a warning but it continued on. and then even if they do
contact the repo admin, the admin will ask them how the error was
trigger and if it's reproducible. which it won't be. and who knows if
the client will work correctly or not? what will be the failure modes
and how are people supposed to diagnose the subsequent random failures?
the repo admin will never realize that some tweaks that they made
resulted in busted clients...
But the client can easily get around that by just doing a pkg refresh
--full or removing the publisher and re-adding them, in which case all
of that's a moot point. The answer is that the repository maintainer
may never know unless users contact them.
If your argument is that more users might contact them if something is
broken, that's fine.
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.
and in any of the possible cases that you site above would you really
want the client to continue to access that repo? (say i'm running b118,
would i really want to refresh my catalogs to a repo that only has
b117?)
Yes, because it is not considered an error if the packages they're using
are no longer present. Remember also that clients will be able to
install packages that came from an on-disk package that may not be
available from a publisher's online repository even though it is from
the same publisher.
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 the client has all the manifest data for packages it has installed
right? why can't we verify this data against the repo.
Because the repository might not have that data, and it isn't required
to. In addition, the catalogs only contain a select subset of the data
that the manifests contain, so we can't actually verify that they
actually match based solely on the content of the catalog.
With that said, as I mentioned previously, I'm working on a revision of
the proposal that includes digest/cryptographic allowances for verifying
manifests.
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.
i'm not sure that driving on is the right thing.
I'll leave it to the consensus of the rest of the team, but this
approach was based on a compromise resulting from user feedback and
various situations that have arisen.
if a repo admin has done something and accidently screwed up a repo,
should clients drive on and propegate the brokeness? i would think not.
We don't know if there *has* been a screwup, only that there *might*
have been. For example, in the case of the sourcejuicer repository,
they actively remove packages and rebuild their pending repository once
packages have been promoted to the contrib repository.
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 not that concerned about the case of a package disapearing from a
repo. that scenario (in my mind) would be more of a warning than an
error. (there'd be no pkg metadata that would be out of sync.) but at
the same time i'd want to know that the repo has stopped serving up the
packages i'm interested in.
And again, as I pointed out earlier, by design, a repository that you've
configured for a publisher is not required to contain all the packages
from that publisher. In addition, a publisher may have multiple
repositories.
It is *not* an error for a package to not be available from any of the
available repositories.
the case i'm more concerned about is if some package data has changed
for packages that are already installed. in that case the client is
broken wrt the server. if you don't want to call it broken then fine,
call it inconsistent. in either case charging ahead seems like a bad
The upcoming revision of the proposal I previously indicated will
include digest and/or cryptographic information that the client can use
to verify the contents of manifests.
Thanks,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
