<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Excellent response...thanks.<br>
<br>
I've been using N800 in 'user' mode mostly and am old rh user expecting
/var/logs, etc. I've wanted to see how far I can go without getting too
messy with n800 as I'm already deep in the doo doo with my PP3 and a
few other devices...don't want to be master of all.<br>
<br>
On an unrelated note...hot damn is the n800 getting sexy. ROR,
Metasploit, skype, j2me, osgi, ...where will it end? Woohoo times are
getting fun.<br>
<br>
<br>
mike<br>
<br>
Marius Vollmer wrote:
<blockquote cite="mid:87644u6n9l.fsf@nokia.com" type="cite">
<pre wrap="">"ext Mike Klein" <a class="moz-txt-link-rfc2396E" href="mailto:mklein@vxappliance.com"><mklein@vxappliance.com></a> writes:
</pre>
<blockquote type="cite">
<pre wrap="">How is it that a package can be marked "Installable" and yet not install?
</pre>
</blockquote>
<pre wrap=""><!---->
A package has status "Installable" when there are no dependency issues
upfront (i.e., no missing packages and no unresolvable conflicts). A
package might still fail to install, tho: it might contain files that
are also in some other package, or one of its maintainer scripts might
fail (or you might run out of storage, etc).
</pre>
<blockquote type="cite">
<pre wrap="">With new firmware I cannot "cleanly" install unzip, wget...as these have
bizarre dependency issues.
With wget I get dep failure of "wget-ssl" conflict...yet I have no wget
on N800 and from googling this appears to be a deprecated package.
</pre>
</blockquote>
<pre wrap=""><!---->
The Application Manager is not smart at all when reporting conflicts.
It might be that the AM picks out wget-ssl as the culprit although it
is not installed. This is probably technically correct, but not very
helpful. In general, if you have bizzare dependency issues, debugging
them with the AM is going to be hard. You pretty much have to dig
into the issue using apt-cache, et al. (I have plans to get more
serious about reporting conflicts in the AM.)
The idea is of course that the repositories don't contain bizarre
dependency issues. But with our bizarre repository landscape, bizarre
dependencies are unfortunately to be expected.
</pre>
<blockquote type="cite">
<pre wrap="">I also tried installing a gstreamer plugins lib (said it was
installable) and it fails silently! Wtf?!? This is linux man. Error
msgs please. There are ZERO dep issues for this pkg and it just
fails.
</pre>
</blockquote>
<pre wrap=""><!---->
Error messages are in "Tools > Log".
Again, the idea is that the maintainer of a package (together with the
maintainers of related packages) makes sure that it installs properly
before it hits Joe Sixpack. For Joe, "Unable to install foo" should
just mean "Foo is broken, gaad dammit, let's try Bar." He is not
supposed to be able to do anything about it.
Likewise with missing dependencies: In the normal world, getting a
package that has a missing depencies means that the distribution you
are using is broken and there is not much more you should do than file
a bug and wait. In the maemo world, people go on a package hunt to
find the missing pieces somewhere in one of the million repositories.
No wonder it gets messy.
</pre>
<blockquote type="cite">
<pre wrap="">I am in redpill mode as I needed root access for a variety of apps.
</pre>
</blockquote>
<pre wrap=""><!---->
(Red-pill mode has nothing to do with root access. It only controls
what packages you see in the Application Manager.)
</pre>
</blockquote>
</body>
</html>