Comment 1 Quim Gil 2008-12-22 15:39:28 UTC

Marius, is this intended behavior or indeed a bug?

Comment 2 Marius Vollmer 2008-12-22 17:10:09 UTC

(In reply to comment #1)
> Marius, is this intended behavior or indeed a bug?

I am not sure what is happening exactly, so I can't say.

Please provide more information.  What is the exact error report of the
Application manager (including the contents of the "Problems" tab.)

What does apt-get -f install do exactly?  Does it remove packages?

What is the content of /etc/apt/sources.list and
/etc/apt/sources.list.d/hildon-application-manager.list?

I have the same problem with pybattery

http://www.internettablettalk.com/forums/showthread.php?t=24905

(deb)
http://www.internettablettalk.com/forums/attachment.php?attachmentid=2944&d=1229898711

python2.5-dbus is installable via apt-get install (but not in appmanager if not
in red-pill).

Attempting to install the deb gives the Problems tab with missing:
python2.5-dbus.

Comment 4 Andre Klapper 2008-12-23 01:30:12 UTC

tz, can you answer Marius' questions?

I replied, but the comments apparently didn't take.  The problem may have
occured while Packages.gz was being updated after the most recent update, so it
is possible that the dependencies were broken when I tried Application manager,
but it was corrected when I tried apt-get.

I don't know how application manager treats deb files - does it install any
dependent packages?

> Please provide more information.  What is the exact error report of the
> Application manager (including the contents of the "Problems" tab.)

I installed it and corrected problems installing it from a repository so it is
installed - I tried installing it as a deb on another tablet and didn't get the
problem but I had other things installed which would have satisfied the
dependencies.  Pybattery gives the same error(s) when I try to install it

> What does apt-get -f install do exactly?  Does it remove packages?

http://linux.die.net/man/8/apt-get

It is a way of bypassing broken dependencies (-f = --fix-broken).  For example
when a package can't completely install or be removed (e.g. the configure is
broken like my reports on /usr/sbin/invoke-rc.d) it will attempt to correct
things and is often successful.

It will NOT install a package that it can't satisfy the dependencies.

But it did find and install python2.5-gnome and -bluez and then install the
main package.

> What is the content of /etc/apt/sources.list and
> /etc/apt/sources.list.d/hildon-application-manager.list?

I will have to grab them from the tablet, but it includes extras.  It had to
since apt-get install worked.

(In reply to comment #5)
> I replied, but the comments apparently didn't take.  The problem may have
> occured while Packages.gz was being updated after the most recent update, so it
> is possible that the dependencies were broken when I tried Application manager,
> but it was corrected when I tried apt-get.
> 
> I don't know how application manager treats deb files - does it install any
> dependent packages?

Application Manager can't fetch the dependencies from the repository when
installing local .deb files. It's similar to use dpkg -i package.deb

While it would be really nice if the AM could to do it, I haven't seen a
package manager in debian/ubuntu (in some years using it) that can to do it.
So, I think it wouldn't be very easy to code.

> I installed it and corrected problems installing it from a repository so it is
> installed - I tried installing it as a deb on another tablet and didn't get the
> problem but I had other things installed which would have satisfied the
> dependencies.  Pybattery gives the same error(s) when I try to install it

Solution: put pybattery in the Extras repository as its dependencies.
Put .deb files in somewhere in web pages is a terrible practice by the
developers specially if those apps need other packages not installed to work.

Comment 7 Marius Vollmer 2009-01-05 10:49:27 UTC

(In reply to comment #6)
> Application Manager can't fetch the dependencies from the repository when
> installing local .deb files. It's similar to use dpkg -i package.deb
> 
> While it would be really nice if the AM could to do it, I haven't seen a
> package manager in debian/ubuntu (in some years using it) that can to do it.
> So, I think it wouldn't be very easy to code.

It's not trivial, but not very hard either.  Patches welcome. :-)

The reason it hasn't been done yet is that, as you point out, installing .deb
files is not a good practice, and is not at all well supported in general.  

For example, when we decide to tighten the signature checks, packages that
don't come from a repository will always be treated as unsigned and likely be
rejected.

Maybe it is a good idea to only allow installation of .deb files in red-pill
mode?

I think requiring red pill for debs would be a bad idea.  You would get far
fewer normal packages, so people would be installing tarballs or doing dpkg -i
from the xterm.  Or you would just get a lot of junky repositories that would
not be maintained well and would only exist to allow deb files to be installed.

The path through extras-devel to extras isn't that hard.  (Though for something
like a single python file it can get annoying to maintain all the packaging
infrastructure since the autobuilder AFAIK only understands dpkg-buildpackage).
 I think the only reason it isn't used more is that there are beta or unstable
versions that you don't want to update on a daily basis.

For me, it would help to have an extras-beta for power-users that wanted the
latest but without the larger instability of extras-devel.  Right now
extras-devel tends to be both, with highly unstable packages (prompting
warnings for users not to enable it), and for betas (when the unstable packages
are released as debs and only in extras-devel when they are close to release).

I'll take a look and see what I can do as far as patches.

A deb in a repository will satisfy dependencies from any other repository which
is active, but not doing so for one outside (e.g. downloaded from the /pool of
the same repository) doesn't seems inconsistent.

Comment 9 Quim Gil 2009-01-06 17:08:55 UTC

According to previous comments this looks like a WONTFIX: we don't want to
support installations from deb packages, nor make their life easy by satisfying
the dependencies automatically. This feature would require extra work and we
don't see this as benefitial as just encouraging developers to user the
maemo.org extras infrastructure. 

Do you agree?

And by the way, since the current behavior is the one wished and specified this
is not a bug but an enhancement request.

(In reply to comment #8)
> I think requiring red pill for debs would be a bad idea.

I actually think that it is a good idea to make life a bit harder to users
willing to install anything not coming from official repositories or maemo.org
Extras. And specially harder to users willing to install single debs found who
knows where.

You annoy certain people (actually the ones that could go through the RedPill
ceremony) and in exchange you diminish the risk of getting in trouble for the
majority of users that don't realize how risky is to install something that
hasn't gone through a documented quality process.


> You would get far
> fewer normal packages, so people would be installing tarballs or doing dpkg -i
> from the xterm.

These are exactly the type of users that could simply activate RedPill.

> Or you would just get a lot of junky repositories that would
> not be maintained well and would only exist to allow deb files to be
> installed.

Junky repos containing junky .debs are basically as bad as junky debs alone.
Another reason to prevent "innocent" users activating them without being
conscious of what is going on.

> For me, it would help to have an extras-beta for power-users that wanted the
> latest but without the larger instability of extras-devel.

And yet another person that thinks extras should fall into the known paradigm
of three levels of stability: stable, testing, unstable (no matter how they are
called finally). Perhaps this is the right thing to do, yes.

As I've railed against before, blue pill is the "padded cell" mode to prevent
anyone from hurting themselves and red pill is the "blow up your tablet now
mode" since the dependencies and lots of other things will be broken even if
the only thing done in red pill is an an update and you return to blue pill.

Red pill mode doesn't just enable one or two useful or potentially problematic
things, it is all or nothing and within the "all" it goes far beyond simple
power-user things and cannot really be undone.

Maybe a green pill mode?

If you make Application Manager too difficult, you will get rogue repositories,
rogue versions of Application Manager or even alternate package managers and
bunches of other problems and lots of unhappy people either unable to install
anything or having to spend an hour just to set it up to install a game.  But
then you will be able to just say "well, that is just not supported".

On internet tablet talk (or the maemo hosted successor) the very first response
to every question will be to enable red pill mode or install an alternate
whatever to access the utility that will allow diagnosis of the problem or
installation of the solution since it won't be doable in any other way with
your ideal AppManager.

Just as I think there is a place for an intermediate between extras-devel and
extras, there should be a place for a middle mode in application manager.  Safe
mode which would be what you describe, advanced power user mode, and red pill
mode, the middle mode would be offered with disclaimer (and restored with the
rest of information after a reflash) and only allow a few extra features like
installing from debs (with dependency satisfaction), maybe adding non-maemo
repositories, perhaps selectively adding sections other than user/*, and such
so power users would never need to enable red-pill but could access the few
needed features.

Right now with just blue-pill/red-pill, you are frustrated that debs and other
things can be installed at all and I'm frustrated that I can't fix their
dependency problems and many other small problems other than with arcane
console incantations as root or red-pill and its associated trashing of the
databases.

Perhaps the best answer is to create a middle ground.

Comment 11 Marius Vollmer 2009-01-07 12:02:02 UTC

(In reply to comment #10)
> Red pill mode doesn't just enable one or two useful or potentially problematic
> things, it is all or nothing and within the "all" it goes far beyond simple
> power-user things and cannot really be undone.

Are you sure you understand red-pill mode?

The potentially dangerous things that red-pill mode allows are:

 - Showing and installing packages that have not been explicitly marked
   as user-visible by the package maintainer.

   This is not really that dangerous, even: these packages will be installed
   even in blue-pill mode if a dependency requires them, we just hide them to
   unclutter the UI.  The danger might come from "power-user packages" that do 
   something nasty when they are installed and are hidden from normal people 
   for that reason.

 - Giving you the option to override the 'package domain' checks.  Usually,
   updates to already installed packages must be signed with the same key.
   In red-pill mode, you can allow their installation anyway, but you have
   to do it for each individual installation, after reading a scary dialog.

Indeed, red-pill mode is less dangerous than apt-get and dpkg (because it still
uses the more conservative update computation algorithms of the AM).

> If you make Application Manager too difficult, you will get rogue
> repositories,
> rogue versions of Application Manager or even alternate package managers and
> bunches of other problems and lots of unhappy people either unable to install
> anything or having to spend an hour just to set it up to install a game. 

Yes, true.  But please don't frame this discussion as "the application manager
versus developers".  (I think the current application manager is very
permissive anyway, even the community is asking for more policy enforcements in
the AM itself, see the Category discussion.)

Standalone .deb packages are not in the 'Maemo spirit'.  This might be
different from other software systems, where binaries are distributed ad-hoc
without any package management and without any central place to host and
maintain them, but they are all doing it wrong. :-)

The grand goal is to remove the concepts of "Catalogues" completely from the
blue-pill UI.  We are quite close to be able to do that, thanks to the great
work by the people who set up extras and extras-devel and who promoted them.

> On internet tablet talk (or the maemo hosted successor) the very first 
> response
> to every question will be to enable red pill mode or install an alternate
> whatever to access the utility that will allow diagnosis of the problem or
> installation of the solution since it won't be doable in any other way with
> your ideal AppManager.

As long as people understand what red-pill mode does, I am not afraid of this.
If people start suggesting the red-pill mode out of superstition, we need to
explain it better.  This has clearly happened, and Ryan did a great job of
clearing up people's misconceptions.

> Just as I think there is a place for an intermediate between extras-devel and
> extras, there should be a place for a middle mode in application manager.  

"Red-pill mode" is actually not all-or-nothing: it's main effect nowadays is to
give you access to a "Settings" dialog where you can tune the red-pill
behavior.

> Right now with just blue-pill/red-pill, you are frustrated that debs and other
> things can be installed at all and I'm frustrated that I can't fix their
> dependency problems and many other small problems other than with arcane
> console incantations as root or red-pill and its associated trashing of the
> databases.

Red-pill doesn't normally trash your databases, there must be something else
going on.  The current Application Manager does a reasonable job of repairing
broken dependencies, I think, as long as the needed packages are available to
it from repositories.  It does this in blue-pill mode as well, of course.

Comment 12 Quim Gil 2009-01-07 12:42:12 UTC

I have rewritten the summary to make it specific to .deb installation.

(In reply to comment #11)
> Standalone .deb packages are not in the 'Maemo spirit'.

(...)

> The grand goal is to remove the concepts of "Catalogues" completely from the
> blue-pill UI.¨

Indeed, and these are reasons good enough to consider this enhancement request
as WONTFIX.

User can install .deb packages and there will be ways for them to do this in
the future as well. But we want to be clear with regular users that
installation of standalone debs is not recomendable and therefore not very well
supported in pactice (no dependencies are satisfied by AM if you want to go
this way).

> EXPECTED OUTCOME:
> 
> It would go get python2.5-gnome and python2.5-bluez from diablo extras and
> then install minigpsd.  This does happen with "apt-get -f install"

Then users willing to go through the path of installing standalone debs can
also open the terminal and follow these or any other unofficial instructions.

Comment 13 Andre Klapper 2009-01-07 20:36:46 UTC

...now I wonder whether bug 3984 is related or not (also installing packages
from a local repo on the device, but AM requiring a network connection).

Unless something is new in the most recent SSU that wasn't in the earlier
version.

Here is what I did (from memory, but I'll try retesting when I have to do a
reflash):

Reflash tablet (so everything is clean).
Start application manager.
Enable red-pill mode. (not changing any default settings, just enabling)
Tell Application Manager to update (I forget if it is refresh or check or both)
Disable red-pill mode.

There were several new packages available in the list, some were libraries or
data that weren't there and don't appear in blue-pill, and I could not get rid
of them by updating in blue-pill or doing anything else. 

Perhaps this is not "trashed", but my point is that entering red-pill will do
things that aren't/can't be reversed by going back to blue-pill.

I didn't report specifics since every other time I mentioned red-pill I got
long rants on how it wasn't supported, I should expect bad things, I'm not
supposed to use it, etc.  There is a list of things which I consider to be bugs
(some more serious than your post would indicate) in red-pill but here again,
they are going to be an automatic WONTFIX, so I didn't bother documenting,
analyzing, or reporting them.

A. Red pill is dangerous, don't ever use it.

B. Red pill only enables a few things which aren't likely to cause problems, so
don't worry about using it.

Which is it?  Has red-pill been improved or fixed?

Should "power users" be encouraged to turn it on now or not?

Comment 15 Marius Vollmer 2009-01-08 11:35:57 UTC

(In reply to comment #13)
> ...now I wonder whether bug 3984 is related or not (also installing packages
> from a local repo on the device, but AM requiring a network connection).

No, it's a separate issue.

Comment 16 Marius Vollmer 2009-01-08 11:57:57 UTC

(In reply to comment #14)
> Unless something is new in the most recent SSU that wasn't in the earlier
> version.

There are some changes, but I am not sure whether they are relevant for your
scenario.  See

   
http://gitorious.org/projects/hildon-application-manager/repos/mainline/logs/release_2.1.19.x 

> Here is what I did (from memory, but I'll try retesting when I have to d a
> reflash):
> 
> Reflash tablet (so everything is clean).
> Start application manager.
> Enable red-pill mode. (not changing any default settings, just enabling)
> Tell Application Manager to update (I forget if it is refresh or check or both)
> Disable red-pill mode.

I will try this.  Did you restore a backup after reflashing or made any changes
to the catalogues?  If so, please paste your /etc/apt/sources.list (if its not
empty) and /etc/apt/sources.list.d/hildon-application-manager.list.

> There were several new packages available in the list, some were libraries or
> data that weren't there and don't appear in blue-pill, and I could not get rid
> of them by updating in blue-pill or doing anything else. 
>
> Perhaps this is not "trashed", but my point is that entering red-pill will do
> things that aren't/can't be reversed by going back to blue-pill.

Yes, if that's the case, then it's very likely a bug.

> I didn't report specifics since every other time I mentioned red-pill I got
> long rants on how it wasn't supported, I should expect bad things, I'm not
> supposed to use it, etc.  There is a list of things which I consider to be bugs
> (some more serious than your post would indicate) in red-pill but here again,
> they are going to be an automatic WONTFIX, so I didn't bother documenting,
> analyzing, or reporting them.

Nonono, using the official repositories or installing a SSU while you are in
red-pill mode is not officially supported: if it fails, you can not officially
blame it on the packages that you are installing, you can only blame it on
red-pill mode itself (for being too dangerous) or yourself (for using red-pill
mode in the first place).

But the red-pill mode itself should not be buggy or too dangerous, of course,
and we are going to fix bugs and misfeatures with it.

> A. Red pill is dangerous, don't ever use it.
> 
> B. Red pill only enables a few things which aren't likely to cause problems, so
> don't worry about using it.
> 
> Which is it?

It's

  Red-pill mode is for digging yourself (or others when helping them)
  out of a hole.  If you still can and know how to do it, use apt-get
  and/or dpkg.  Don't leave your device permanently in red-pill mode;
  only enable it temporarily when it is needed to fix something.

> Has red-pill been improved or fixed?

Constantly. :-)  We have changed the defaults to make it more similar to
blue-pill mode, and it now turns itself off when restarting the Application
Manager.

> Should "power users" be encouraged to turn it on now or not?

Only temporarily, as explained above.

Thanks for the clarification on "red-pill".  I was hearing a lot of
contradictory things on how it should be used (perhaps it should be a deep menu
item and only last one session).

The noted red-pill problem was on a clean (Flash to the next to last
RX-34....bin) and I did NOT restore anything though I might have installed some
app from the available stock repositories and/or set things required like time
and wireless.

I now have 3 tablets (one each, RX34, 44, 48), and one reason is so I can use
my normal tablet for daily use but develop or check such things out.

(Actually I just reflashed my old n810 to 5.2008 so a friend could try it so I
can check...)

It is apparently a problem in the packages or the repository, not something
unique to red-pill:

Browse Installable applications -> Navigation shows: maemo-mapper-topomaps-fi
In BIA -> communication, "libuiw 0.0.28" shows up.

These two should only be installed as dependencies or at least with
dependencies.  Extras is NOT enabled, so maemo-mapper isn't available and
shouldn't be pulled in with the topomaps.

I will recheck other things which I may have mistakenly blamed on red-pill.