James C. McPherson wrote:
On Thu, 25 Jun 2009 10:50:25 -0700
"James C. Liu" <[email protected]> wrote:
...
1. A number of packages in the IPS repository are not x86
architecture. The GUI stops and prints detailed errors.
About 2 dozen of these interspersed in all the packages
make it impossible to select ALL categories and ALL packages
and install ALL. So I need to manually go through and
de-select those that don't pass muster. Can't tool just bypass
skip and recompute dependencies?
There are enhancements logged to not list packages that are not
available for your architecture. But I have to wonder why you need to
install 'all categories' and 'all packages'.
Sun (as I understand it) is moving away from that great big "blob o'
stuff" at install time, and moving towards a "supported core" where you
add just what you need to it.
Note that over time, the number of available packages will likely grow
to be significantly larger than what Sun even provides for SXCE now, and
installing "everything" will be impractical or not terribly useful.
However, there is a much easier way to accomplish what you wanted. Just
install the 'redistributable' package. That will install every single
package that is part of the OS distribution, although unbundleds such as
Sun Studio will still have to be installed separately.
2. Mid-way through updates/installs of new stuff, I can
no longer install -SOME- of the selected packages. There is
no warning. Instead, I need to read the details carefully
and realize that only 10% of the selected packages I want
updated are actually going to download and install. After
a certain point, the GUI tells me I can't even update/install,
but need to UPDATE ALL. It takes quite some tries to get to
this fully saturated install state. The first time this
happens is about 900MBs after new installs occurs. I am then
forced to generate OpenSolaris-1 boot.
There isn't sufficient detail to comment here. I'm not certain what "I
can no longer install" means, or what "realize that only 10% of the
selected packages I want updated are actually going to download and
install".
3. Depending on the order of installs, about 600MB or 1.2GB
into further installs, I encounter the same error as in 2.
And am forced again to UPDATE-ALL. This generates OpenSolaris-2
boot environment.
What error do you encounter? What are you doing an Update All for?
4. On one of my systems, where I installed Applications first
then System category next, I actually had to repeat install for
OpenSolaris-3 boot environment.
Again, there's something missing here.
All the while, the packages are brutally slow to download and
appears to constantly stall during download phase. I'm informed
of a percentage complete, but no real information as to why
I'm stalling. And the update-phase in an "UPDATE-ALL" situation
The existing transport system was written using Python's standard
libraries, and we have found them to woefully inadequate. That's why a
completely new transport system based on libcurl will be putback soon,
and hopefully you will see improved transfer performance and progress
information.
is brutally slow as well. It could be updating stale
dependency checks, but that seems really flawed as the installation
phase should be amortizing this cost at the point of installation.
There are no 'dependency check' updates going on here. Most of the plan
creation delay you see currently is the cost of two things:
* the retrieval of package metadata (about 65-80 megabytes for an
upgrade from one build to another)
* dependency calculation
I'm not certain what you mean by installation phases amortizing the cost.
I'm not certain why the update phase is "slow" for you as that is almost
completely I/O and memory-bound.
I'm able to update my entire system (assuming all the package content is
cached in /var/pkg/download) from one build to another in less than five
minutes.
When you say update phase, can you be more specific?
Total time averages about 6.5 hrs to install what used to take
about 45 minutes. I thought IPS was supposed to be faster.
I'd personally take a DVD and be done with it in the same time
if that would decrease network latency problems.
Obviously installing from a DVD is going to be significantly faster than
installing from a network server; there's no way around that. But the
last time I tried to install redistributable, I don't recall it taking
that long.
It is regrettable that you encountered the issues that you did, but be
aware that more improvements are coming. Although, it appears most of
your frustrations could have been solved by simply installing the
'redistributable' package instead of attempting to manually install
packages from each category.
1. most folks on windows/linux expect default behaviour to
download packages for update without intervention. If we could
just bypass bad packages and automatically recompute dependencies
without the bad package, that would be ideal. The guarantee we
need to provide is when the user clicks the update/install button,
it happens, so he doesn't leave, then come back hours later only
to find that it stalled 5 minutes into the operation.
Those aren't bad packages; they are packages you specifically requested
for install and the system can't install them. Arguably, the GUI
shouldn't list them, but as I said before, installing 'redistributable'
is the easier way to do what you wanted.
2. Buddy-boot/auto-share/torrent - our server is bogged down a lot
and they are changing and updating, if snoops on the latency are
any indications. I need to have an onboard repository that is
auto-configured to cache and share the packages with anyone else.
This is already planned functionality for the far future (torrents,
auto-sharing, etc.), but we need a new transport system first, and as I
mentioned above, that is coming very soon.
Rather than having the default to go back to opensolaris or ipkg.sfbay
to get packages, we should download meta-data manifest and share
what we've archived, and archive the packages. Currently, there
is some signing and secure-auth that requires me to read a manual
and then install my own repository to serve up packages. That's
too much burden, IMO for customers who will balk at the idea. RPMs
are indivdually signed and verifiable. I often have used up2date
or apt and archived them and re-installed on all my home systems
without issues and no documentation. It was intuitive and saved
tonnes of bandwidth and fast too. If we had some feature to share
downloads easily, that would be great.
On-disk format design and implementation will start later this year. In
the near future though, we will be releasing ISO images of the 2009.06
repository with instructions on how to setup your own local package
repository for faster, local network access.
My personal experiences are fairly representative of what external users
would see as I use the package server from Kansas; not from MPK :)
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
