5402
Comment:
|
5429
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