Differences between revisions 18 and 19
Revision 18 as of 2006-12-13 15:10:50
Size: 5402
Comment:
Revision 19 as of 2006-12-14 05:41:20
Size: 5429
Editor: ?AlphaPapa
Comment: Suggestion for Upstart
Deletions are marked like this. Additions are marked like this.
Line 48: Line 48:

 * Why not use Upstart?

This is a page intended for brainstorming and outlining useful improvements to Debian as a whole, parts of it's infrastructure, it's packaging system etc. If the description of the specific feature gets long please create a new page and link to it instead and just keep the short description on this page (consider [wiki:HelpOnEditing/SubPages ?SubPages]). You might want to list "dependencies" and potential returns that this feature would provide. It would also be interesting to differentiate the low hanging fruits from the ones that require more work, so -- if you can -- you might want to add a tag like "big effort", "quick", "long term" or a timeframe you think might be appropriate. If you know people interested in working on this, even that could be useful to add.

A possible example might be Multiarch:


Multiarch directories

Using architecture, kernel and libc/abi specific directories to store libraries and plugins (e.g. /usr/lib/i486-linux-gnu). This way libraries and plugins using glibc and uclibc can be stored on the same system or kfreebsd and linux (since bsd can run them too), or mips and mips64, ....

  • depends: pending multiarch patch for binutils

    provides: disjunct locations for every arch-kernel-libc/abi combination

    effort: trivial, whenever the maintainer feels like it

    prerequisite for: multiarch


Multiarch

Integrating mulitiple different binary architectures (e.g. i386 and amd64) in the same filesystem in a transparent way.

  • depends: multiarch directories, dpkg with multiarch patch | dpkg2

    provides: improved system integration

    effort: big, one year

    interested: Matt Taggart, Mithrandir


More Debtags support

[http://debtags.alioth.debian.org Debtags] is getting mature, and there are now working prototypes of [http://debtags.alioth.debian.org/ssearch/html smart search and navigation interfaces]. The algorithms are easy. Synaptic and Aptitude should benefit. Mail Enrico for instructions and help.

  • depends: debtags or libept-dev or python-debian or can be reimplemented from scratch with the data in the Packages file

    provides: allows users and developers to find packages with little effort

    effort: small to moderate. Most of the effort is in designing how to blend the features into an existing interface, rather than the implementation itself.

    interested: Enrico Zini


Faster Boot

Reducing boot and shutdown time, dependency/event based init scripts

  • provides: faster and more consistent system initialisation

    effort: medium, partly done (Google summer of code 2006)?

    interested: hmh, pere

  • Why not use Upstart?


Debian Desktop

The [http://www.debian.org/devel/debian-desktop Debian Desktop] subproject is composed now by members of pkg-gnome, pkg-kde, pkg-xfce and others. It has a common project and svn repository (debian-desktop) in alioth. Debian Desktop has input on desktop and laptop tasks package selection (tasksel project) and is working on common artwork as we speak (desktop-base package).

  • provides: A better Debian Desktop.

    effort: medium, almost done for Etch but will require much more work for Lenny

    interested: stratus, debian-desktop@lists.d.o subscribers.


dpkg2

dpkg needs a rewrite and extensions

  • provides: more flexible low level package manager.

    effort: not sure

    interested: not sure


Translation Debs

Special packages that are language oriented. Each package has its own set of complementary .tdebs, one per each language. This feature was discussed lengthly during [wiki:I18n/Extremadura2006 the I18N meeting in Extremaduara] (Sept. 2006)

All localization information is split from the debs, allowing the binary packages to reduce their sizes to the minimum. The users get only the loaclization material (.mo files, localized sounds and images etc.) that they choose via specific settings, making [http://packages.debian.org/localepurge localepurge] obsolete.

This feature would be beneficial to:

  • our users
    • only the needed info is downloaded
    • translation updates could be done after releases (tdebs would have a separate source package after the release - more info on the [wiki:TranslationDebs Translation Debs] page), thus errors, upstream updates could be imported

    • translators (lower importance packages, could be accepted easier)
  • emdebian
  • our mirrors (less traffic since only useful material is downoaded)
  • package maintainers (could allow translation package management to somebody else)

Overview:

  • provides: split translations, several benefits, see above

    depends: multiple changes in apt, changes in dpkg-buildpackage(?)/create an utility to automatically create source tdeb packages from the original debian source package (needed later in order to create separate translation updates), dpkg changes in order to store the translation information (better to be in a separate directory) and associated maintainer scripts; dak changes to support tdebs (which should be in a different area of the archive than the regular debs)

    effort: big, maybe could be done for Lenny - needs changes in apt and dpkg need to be though carefully; archive needs changes

    interested: Eddy Petrişor, Debian I18N Task Force