[maemo-developers] Public maemo repository

From: Daniel Stone daniel.stone at nokia.com
Date: Mon Jul 30 15:15:50 EEST 2007
On Mon, Jul 30, 2007 at 02:03:53PM +0200, ext Kees Jongenburger wrote:
> On 7/30/07, Daniel Stone <daniel.stone at nokia.com> wrote:
> > On Fri, Jul 27, 2007 at 09:14:09PM +0200, ext Kees Jongenburger wrote:
> > > What kind of step does a "user" have to take between creating it's own
> > > package and the sbuild/buildd/debuild aproach? isn't this hole
> > > open-source thingy about giving power to the user?
> >
> > It depends entirely on the tools.  You could easily construct an
> > improved dh_make that required no editing of any files at all.  It has
> > nothing to do with the packaging system itself, as cdbs's three-line
> > debian/rules files have shown.
> I am really not trying to be annoying or anything I really am trying
> to understand.
> From my point of view as "user" as you call them has no access to the
> sbuild/buildd/debuild system, they get an sdk and that's it, Creating
> an
> improved dh_make , recompiling the package to use the thumb
> instruction set or not, are simply not part of the things that can be
> done (or am i missing the big picture?)

Sorry, I completely misread your question.  As for the build part,
again, this is just a question of tools, and not a fundamental
limitation of the packaging system.  Something like pbuilder almost
certainly does what you want.  (That our SDK could certainly be improved
is a separate issue as to whether we should use OE/BitBake or Debian

> > > If you are using dh_make you are not using the "power" of the existing
> > > debian packages and you are in trouble
> >
> > Who was saying this?  Using dh_make is fine.  If you want your packages
> > to be good, then you should clean up the template a bit, yes.
> I guess it's fine as long as it's you own software you are packaging.
> I understand that one must put some effort in packaging. I was
> referring to the "missing"  libs like some sdl packages or  sqlite3
> etc. I you run dh_make on those
> your a in trouble since different packagers will give the libs
> different names/options.
> Again am i missing the big picture or how do I get sqlite3 in maemo?

Usually, you just take the sqlite Debian package, and build it in a
Maemo SDK.  Again, the problem you mention is completely independent of
the build system: I could create a BitBake package called 'sqlite' and
you create one called 'sqlite3', and we have exactly the same problem in
another packaging system.

> > > if you don't use dh_make and try to use upstream packages + patches
> > > you are in trouble because you are creating the chaos youself, You are
> > > also prooving that  the initial "source" packaging was not sufficient
> > > for your need
> >
> > I don't see what you mean here?
> This is again about the differences between maemo .deb packages and
> mainstream packages they are not the same and maemo as community does
> not provide a place to upload those changes/patches. When nokia
> chooses to create a new distro people are constantly trying binnay
> packages of exiting app that where ported earlyer in the hope it sill
> works. IMHO not an optimal solution

Yes, again, we could've done a lot better on the SDK/distro side of
things, but this is also a separate problem from the packaging system.
Most Debian packages won't work (unless you use the new armel port),
because we use EABI and Debian's arm port doesn't -- mismatching
toolchains generate incompatible binaries.

We should be a great deal better at giving back to Debian in general,
and working to develop better-integrated support for cut-down systems
(embedded and consumer devices), so you can take packages straight from
Debian and build them with no changes (as opposed to the Emdebian
approach).  But we haven't been, and that -- like the others -- is
another problem with the approach we've been using, not our packaging

> > > I think there is a big difference between those systems. Me as
> > > developer ,I have the same tools as you the packager (as I tend to
> > > call people who create packages)
> > > bsd ports,gentoo portage and oe contain meta packages.
> > >
> > > lets' face it what good did the packaging bring maemo until now? I
> > > don't understand I am still waisting my time with this packaging
> > > issue.
> >
> > The possibly to derive from an existing system, not having to invent our
> > own packages or tools to solve problems that have already been taken
> > care of long ago?
> :P I understand but just try to be on "my" side for a few minutes. I
> am experiencing
> the complexity of the debian packaging with the tweaks required for
> the maemo platform. I was not born as debian developer. I really did
> not care about repositories, free non-free stable unstable . I did not
> care about arch, I did not ask for dh_make. dpkg-xxx. All I really
> want is to be able to share software, and improve existing software
> for the arm platform (like sdl). The current packaging does not make
> it easy to do either. I hope that this will improve in the future.
> just having a public maemo repository is not enough.

% dh_make
% debuild -us -uc (or, if you have a broken Scratchbox:
  dpkg-buildpackage -rfakeroot -us -uc)

And debs appear.  They'll work, but probably won't build automatically.
For that, you need to list your build dependencies, etc (same as
ebuilds, at least).

If you want to tweak existing packages (apt-get source foo), then yes,
some of them are a bit complex, because of the flexibility they offer.
Similarly complex ebuilds exist, and I'm sure you can find similarly
complex BitBake files.

free/non-free/stable/unstable aren't a Debian packaging thing (many
repositories are structured differently, such as our internal one for
example, and many only have one tree).  It's just that Maemo chooses to
distinguish free and non-free software, and it chooses to allow you to
work on two distribution branches.

I don't think most of your problems would be solved by simply exchanging
.deb for .bbk (or whatever BitBake is).


More information about the maemo-developers mailing list