[email protected] wrote:
Hi Joanie,
Well, it's not *that* long. :-) Admittedly I tend to upgrade to the next
dev build as soon as I see the release announcement so I suspect I'm
just hitting the servers at the same time everyone else is. :-) But I
happen to be in New Hampshire, so if you have a greater Boston area
mirror, that would be cool. I looked around at opensolaris.org but
didn't see a list of mirrors for pkg.opensolaris.org. If you have a
link, that would be great. Thanks!
The Burlington site has a mirror on SWAN (ipkg.east:8000), but there
don't appear to be any public mirrors available right now. We've
published the instructions and the bits, though, so anyone should be
able to set one up.
http://opensolaris.org/os/project/pkg/Mirroring/
When I download files in a browser or ftp client, when I transfer files
in a file manager, when I check my email, when someone is sending me a
file via IM, when I perform just about any task that has the potential
to take more than a few seconds and/or timeout due to a connection
failure, there's a Cancel button of some sort. In other words, as a user
I can always gracefully bail out of these tasks using the functionality
provided to me by the app in question. Why is this not the case when I'm
trying to add a repository that doesn't want to respond in a timely
fashion? I shouldn't have to do a force quit of packagemanager IMHO.
The short answer is that the first version of the pkg client was
designed before the GUI was written. The common code has a bunch of
assumptions built in that are safe for CLI operations, but not
necessarily user friendly when applied to a GUI environment. There's a
RFE open for the ability to cancel file downloads once they've started.
http://defect.opensolaris.org/bz/show_bug.cgi?id=4495
As part of the transport framework replacement, I'm planning on fixing
this post 2009.06. There may also be API considerations here, since the
API defines what operations can and cannot be cancelled, but we should
be able to resolve any concerns.
John's fix works nicely and makes the interaction with packagemanager a
lot more clear given the conditions in question. (Thanks John!!) And I
was going to just let this issue be. But when I saw y'all discussing the
overriding of variables, it struck me that what you were discussing
might not be necessary -- or ideal?? If the user of the gui is given a
way within the app to gracefully bail when faced with a non-responsive
repo, is there still a need for the gui to override PKG_CLIENT_TIMEOUT
and/or PKG_TIMEOUT_MAX (checking first to ensure that the user hasn't
created his/her own environment variable)?
A graceful bailout is the correct long-term solution, and it's in the
works. I assumed that our discussion about overriding environment
variables was simply a interim workaround in case this problem turned
out to be unbearable.
Joanie - just catching up on email.
Yep long term we want users to be able to cancel any of the transport
based operations any time they want to (with some minor delay in the
cancel operation itself being ok). At the minute this is not possible in
all instances. As soon as an api operation becomes cancellable we will
add the Cancel option to the relevant dialogs in the GUI. This has been
done for some operations already, but not adding a repo :(
The environment variable settings is a good workaround for now, post
2009.06 we can do a lot better with J's transport layer rework.
JR
HTH,
-j
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
