Differences between revisions 31 and 32
Revision 31 as of 2007-04-18 16:00:46
Size: 11520
Editor: EddyPetrisor
Comment: better layout
Revision 32 as of 2007-04-23 03:24:33
Size: 12418
Editor: ?AlphaPapa
Comment: Idea for upgrade testing with UnionFS/AUFS
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:

----
== Upgrade testing with UnionFS/AUFS ==
After reading [http://michael-prokop.at/blog/2007/04/22/booting-from-usb-pen-troubleshooting-and-pitfalls/ a blog post about problems upgrading from Sarge to Etch], it occurred to me that a handy feature would be the ability to run an upgrade test using UnionFS or AUFS to see what problems may be encountered after the upgrade, without actually modifying the existing system. It wouldn't require as much disk space as cloning an entire system, and if the upgrade didn't go well, a simple reboot without UnionFS/AUFS would return the system to the pre-upgrade state. A notable problem would be that data could be modified on the system during the upgrade test (e-mail, database, etc), and such changes would be lost when reverted; care should be taken to prevent mail servers, databases, etc. from accepting changes to their data during testing.

This is a page intended for brainstorming and outlining useful improvements to Debian as a whole, parts of its infrastructure, its 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:


Upgrade testing with UnionFS/AUFS

After reading [http://michael-prokop.at/blog/2007/04/22/booting-from-usb-pen-troubleshooting-and-pitfalls/ a blog post about problems upgrading from Sarge to Etch], it occurred to me that a handy feature would be the ability to run an upgrade test using UnionFS or AUFS to see what problems may be encountered after the upgrade, without actually modifying the existing system. It wouldn't require as much disk space as cloning an entire system, and if the upgrade didn't go well, a simple reboot without UnionFS/AUFS would return the system to the pre-upgrade state. A notable problem would be that data could be modified on the system during the upgrade test (e-mail, database, etc), and such changes would be lost when reverted; care should be taken to prevent mail servers, databases, etc. from accepting changes to their data during testing.


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.


Single Sign On / Adaptability

We should make it as easy as possible to introduce a new service or a computer in the network, with full access to printers, files etc. There are a lot of different LDAP chemas and mechanisms to give users access to different system services as sound, direcotries etc. This leads to difficulties to access standard system resources when upgradring the system or integrating a new PC to the network. One example is handing [http://lists.debian.org/debian-devel/2006/10/msg00752.html device permissions] that removes sound support when upgrading from Debian Sarge to Etch. An other example is to integrate a Ubuntu-based or a Windows laptop on a Skolelinux network.

To improve the features that support this enterprise desktop requirement by harmonising directory settings and working on support for single sign on technology in relevant technology such as [http://docs.kde.org/stable/en/kdeutils/kwallet/index.html KWallet] and [http://ftp.acc.umu.se/pub/GNOME/sources/gnome-keyring/ GNOME Keyring].

  • provides: Enterprise Adaptability (e.g schools, small and medium sised businesses)

    effort: Developer gatherings and coordination with projects as KDM, KWallet contributors and relevant kdelibs developers. GDM, GNOME Keyring, Gnome-libs. Samba, Kolab, Scalix, Asterix, OpenXChange, ?OpenGroupware projects to work on directory harmonisation. Relevant for Linux distributions such as Skolelinux, Debian, Edubuntu, K12LTSP, ?LiMux, mEDUXa, User Linux etc.

    interested: KDE developers, Skolelinux <fixme: we need to promote this>


Desktop Accessibility

Accessibility is mandatory property for computer systems in private companies and public sector. Blind persons will prefer a text based interface reading the "screen" on a screen reader. Different projects has targeted accessibility that makes it easy for disabled people to use a computer system. As a part of The Portland Project (managed by OSDL) they are migrating the desktop messaging systems to D-BUS to enable cross-desktop interaction. Then KDE and GNOME got an outdated accessibility support. Both GNOME and KDE developers work together enabling accessibility. The support should also be easy to install and use on a Debian based system. Since Debian is one of the major distributions in schools, we could be left out from public tenders if the accessibility support lacks.

http://www.osdl.org/lab_activities/desktop_linux

  • provides: Desktop Accessibility "out of the box" for disabled persons

    effort: half man year

    interested: Klaus Knopper, OSDL, KDE developers, Gnome developers


Development Environment (out of the box)

Developer tool readiness student projects and free software developers programming end user applications in C++ or some other language. It often takes a day or two to configure a developer environment when installing a Debian system. Even if the tools are easy to install with apt-get, some additional configurations has to be done. Then people need 1-2 full days to configure the tools.

  • provides: LSB developer tools "out of the box" with programming Workbench, Unified Modelling Language tool, project planning tool etc.

    effort: half man year

    interested: KDE developers, Skolelinux


One Laptop per Child support

The One Laptop per Child project are targeting millions of pupils in development countries. The prototype runs a light weight destkop with full support for video streams and Internet. Memory footprint on the OLPC-device is 128 MB RAM and 512 MB harddisk on flashRAM. Then programs as OpenOffice.org and other "fat" software is out of the question.


dpkg2

dpkg needs a rewrite and extensions

  • provides: more flexible low level package manager.

    effort: half man year

    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 at length during [wiki:I18n/Extremadura2006 the I18N meeting in Extremadura] (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 localization 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 translation error fixes and upstream updates could be imported. New translations could be added (is this acceptable for a stable release?).

    • translators (lower importance packages, could be accepted easier)
  • emdebian
  • our mirrors (less traffic since only useful material is downoaded)
    • RaphaelHertzog: this is not necessarily true, the biggest mirrors are afraid of having many small files to download instead of only some big files. Each new file usually means a disk seek which is costly compared to loading more contiguous sectors from the same file...

  • 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 a 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


Less spammable addresses in Debian

It should be fairly trivial to list in the web interface of BTS and Debian mailing lists non-spammable email addresses instead of the legal ones.

  • provides: less possibility to be spammed

    effort: probably small, 2-3 weeks(?)


Student DD's in Google internships and Google Summer of Code projects

Match as many large bug fixing and general enhancement projects and student developers as possible with internship and summer-of-code hosts inside Google. Some with traction already:

  • kernel hacking and packaging
  • automated testing and emulation environments
  • repository tool development (eg. http://code.google.com/p/debmarshal )

  • configuration file management tools
  • nscd and ldap bughunting and enhancements (eg. http://code.google.com/p/gnscd )

  • kerberos
  • debian-installer automation
  • general bughunting or enhancing any other common free software project

Feel free to suggest/volunteer for/offer-to-host others.

"interested:" Drake Diedrich

"effort:" ongoing


Diversions for debconf-generated configuration files

dpkg-divert may be used for regular package files and conffiles, but does not divert files managed by debconf. In enterprise deployments, the required configuration files are often not possible to generate using debconf, and relying on debconf to generate them is unreliable. Supplying exactly what is desired in the file is the desired behavior, but there is no systematic way to prevent a package using debconf from overwriting them.

"effort": A few weeks to create the diversion infrastructure, then many months sending patches to packages to use that infrastructure.

"interested": Drake Diedrich