Distro-Zen question of the day


9 Responses to “Distro-Zen question of the day”

  1. 1 Nestle

    Simple. Switch it to QT.

  2. 2 foo

    I would like to see Maemo the distribution and Maemo the community both fully merged into the Debian project.

  3. Can you elaborate, please?

    See also http://lists.maemo.org/pipermail/maemo-users/2008-October/022939.html

    Tha approach to Debian (or Ubuntu, or whatever project you have in mind) probably needs to be done through progressive steps. Ideas for a first, very practical step?

  4. 4 knuddeler

    First practical step:
    Make busybox and coreutils work perfectly together.
    So the system can boot with busybox but coreutils/bash/etc. can be installed in parallel (alternative: use coreutils/bash all along).

    Second practical step:
    Identify all packages that have relevant (Nokia) changes compared to upstream (Debian/Ubuntu) versions and list them. Gtk+, cdbs, shared-mime-info, etc comes to mind.

    Third practical step:
    Try to find proper solutions for all relevant packages to make them either obsolete or integrate them with consistent versioning (the “-maemoX” is a good start) to be compatible with upstream versions. (Read – keep patches to Gtk+ in separate .diff files and let dpkg/cdbs handle patching and keep Gtk+ Version aligned with Debian/Ubuntu one).

  5. very good proposals! Feel free submitting them as enhancement requests at bugs.maemo.org. Same for more ideas to come. Let’s also have a wiki page concentrating all the relevant information.

  6. @knuddeler: http://wiki.maemo.org/Mainstream_Linux_Alignment created, your 3 proposed steps are now filed as bugs and listed there.

    Watch that wiki page and add get CCed in the bugs CC to be involved and follow the progress.

  7. 7 tz

    Part of the problem with Busybox is that it is configured with Nokia’s choices.

    One of my biggest annoyances is with the lack of Mac partition support in the kernel. It can be gotten around with a userspace program and the loopback driver, but losetup or the equivalent mount option set is NOT in the distributed version of Busybox. Since the other utils won’t install cleanly on top, I can’t mount the partition even if I can find it.

    So it is more of a tri-lemma. We can’t get a fatter busybox so as not to need coreutils, coreutils doesn’t coexist nicely, and the stock busybox has stuff missing.

    (Sorry to repeat from my original communication elsewhere)

    And I also note that there are things in the SDK or tools which are utilities or libraries which are not visible outside of red-pill mode and/or adding the SDK and tool repositories. And they’re not likely to work in scratchbox (e.g. l2ping).

    I can see that Nokia would want to distribute a minimalist busybox, kernel, and set of tools, but that for some applications, it needs to be widened or at least there should be some mechanism that would allow enhanced versions to be distributed as ordinary debian packages. Or simply fattening busybox (turn everything on, all options) might limit the need for extra packages or coreutils.

    One of the things which is a dichotomy on the tablet but not in the distros is the idea of a development v.s. target platform. Even on my Zaurus I installed native gcc toolchain and vim and lots of other things. My PCs (laptops, desktops, PowerPC Mac or Intel 32 or 64 based) don’t have a difference, at least not after I do a few ordinary (nothing like a red-pill mode) installs using the standard tools. There should be a clean way to add the devtools to the tablet itself, or at least enough of them and have things work normally. Trying to keep a split is going to make the rest of the goals harder to achieve.

    And you could include Python and all the hildon+ packages (bluetooth, gnome/vfs/gconf, hildon-desktop-plugins) in the base. This would encourage using them and fixing anything missing since you could then just run the .py file instead of having to find a package that happens to import what you need and have the installer resolve the dependencies.

  8. 8 Thomas

    One of the things that surprised me immensely (being somewhat involved in Debian) is how maemo seemed to have borrowed some technical stuff from Debian but has processes that looked completely improvised. Contrast that to e.g. Ubuntu: They more or less took the Debian process and then deliberately changed it (and did a lot of changes there, but to things they identified as broken). The experience of too many repositories (note that maemo explicitly designed app manager to make adding repositories a thing to be done more or less unconciously), too many categories, could have been avoided here.
    Running package repositories Debian-style (the infamous NEW queue, uploaders – Ubuntu changed who-can-upload-what away from all or nothing, so did Debian with it’s “Debian Maintainers” concept) is expensive if not prohibitive, but does serve the purpose of balancing the decentralized maintenance with the user’s expectation of a coherent distribution. Recently, people seem to put in work to improve some of the coherence problems of maemo and that can only be a good thing.

    The coherence theme is for development, too:
    Ideally, I could take any package on the tablet and do apt-get source XXX to get the source (neatly split into .orig.tar.gz and .diff.gz) when I want to look into changing something, create and test my patch, and then send a bug report and diff somewhere. Of course, that is my Debian expectation of how things work and the details might be different, but the important thing is that when looking at a bug I should be able to see what’s going on just by starting from the package name (and then have an URL like bugs.maemo.org/$PKG and something like Debian does with packages.qa.debian.org/$PKG) to find everything I need to get my fix to the parties in charge easily. I don’t want to have to search the garage project for what generates that package and then some more to find the svn in which they might have source. Maybe I was just confused the last time I tired, ( http://repository.maemo.org/pool/ looks like a good starting point to find sources, but I wonder why you chose to use a fake pool instead of a proper pool – sorted by source package, not release – layout). Of course, all of this would make it only easier for people that a) look into lots of things and want the “looking into” involve as little hassle as possible b) already know part of it from Ubuntu, Debian, or whatever.

  9. Simple … ban QT !
    You will be the first distro to do it.
    Sorry … just a troll for the first comment….

    I think something Maemo need is more developers … Maybe more ads …
    Many people i know never hear about Maemo or Internet Tablet Product. Yes i know, it s really difficult to made a reputation in this Open Source Distro World 🙂 But know that Maemo exist is the first step … and after it ll be easy to demo that Maemo is a good distro for mobile device …

%d bloggers like this: