Johan,
at least on the surface, that doesn't seem to be the case.
An application I'm trying to install depends among others on
libsigc++-2.0-0c2a. The application's category is properly set to 'user/other'
- so there is no conflict there. Also, my application's dependencies are set to
${shlibs:Depends}.
The libsigc++-2.0-0c2a's category is set to 'devel' - which make it 'invisible'
but as you said 'installable as a dependency'. When I try to install my
application with Application Manager, its 'Status' is marked as 'Not
installable' and the 'Problems' tab lists the following causes:
Unable to install application
Application packages missing:
hildon-fmmm
hildon-libsmm
libglibmm-2.4.-1c2a
libgtkmm-2.4-1c2a
libsigc++-2.0-0c2a (>= 2.0.2)
When installed in ARMEL scratchbox, the application properly reports the same
list of dependencies (plus all base system libs). So, the naming of
dependencies is correct, and the repository is accessible, yet they are not
pulled and installed as expected.
On the n800 itself, if I became root, then I could install everything including
libsigc++ in one sweep with 'apt-get install hildon-fmmm hildon-libsmm', but
for every package I get this:
WARNING: The following packages cannot be authenticated!
package list...
Install these packages without verification [y/N]?y
So, perhaps what holds Application Manager back is the fact that these
libraries are not signed?
--Vlad--
-------------- Original message ----------------------
From: Johan Bilien <[EMAIL PROTECTED]>
> On Mon, Mar 26, 2007, VLG wrote:
> > Further digging reveals that starting with libsigc++-2.0-0c2a,
> > the 'Section: libs' in debian/control file is considered a violation
> > of some sort. osso-application-installer insists on having 'Section:
> > user/FOO'
> > as the least.
> >
> > I am afraid, all the packages have to be rebuilt, signed, and uploaded
> > again.
>
> I believe having libs (without user/ ) won't prevent the packages from
> being installed as dependency of another package, they will just not show
> up in the Application Installer list (which is probably the best
> behavior anyway). Marius correct me if I'm wrong.
>
> --
> Johan Bilien
> <[EMAIL PROTECTED]>
_______________________________________________
maemo-developers mailing list
[email protected]
https://maemo.org/mailman/listinfo/maemo-developers
