To Do

Random collection of ideas for Debian's future:

Redesign most things, fork a new distro. Do not hear to bull-headed developers. More flexibility with autobuilders, allow definable targets, depending on the environment.

Die Testing, die.

Replacement: Recompiled backports when needed:

 --> Unstable -> Pre-Working -> Working -> Stable

"port chains" with maintainers responsible for controlled movement of package series to the next step, like "Perl translation". This also makes gradual releases possible.

Maybe even by doing multiple "distributions" and let "unstable" be just a merge of some of these trees. That would allow people to leave out "games" etc. Ideal would be a hierarchical multiple-level-and-multiple-branch structure and the user can construct his own local package index: leave out unneccessary sections and limit the neccessary section size to the most-popular-level packages.

Tolerate RC bugs in few packages, decission is made by a committee.

RC bugs are bound to the architecture and package version.

Create a metapackage "real-stable" which conflicts with all packages (versioned!) that are RC buggy.

Intelligent "Closes" handling, never close the bug until is has been fixed in Stable.

In our apt-replacement, fix the package / index path handling. It should be more mature, maybe tolerant for user errors or generate a list of possible location by just scanning the peer directory structure (the evil guess-how-the-deb-line-should-look problem).

Completely Unicode based (UTF-8), wrapper solutions for non-UTF-8 aware applications where needed.

A large file database for all files and packages (UPS: Universal Packagement System). ABI and Architecture handled as another relationships.

Package relationships: as in Debian, but kick Enhances, Build-* and implement:

Conditions in all variables, virtual condition packages like "build-env", "i386", "ABI:c++102".

Tagged Provides, implicite tag is the version, optional tags like "ABI:c++102" possible

Rated(!) hierarchical keywords for packages instead of secion, including: Subject of Application (like "web browser"), type of package ("daemon", "library", "devel", "meta"...), stability/maturity (rated! apache deserves 1.0, apache2 maybe not yet), ease-of-use (rated!), user interface ("gnome", "console", ...), freedom (default: 1.0 for gpl; maybe 1.1 for bsd; < 1 for non-free)

Priorities of package may change depending on user's keywords and keyword rating.

Rating system should idealy be detached somehow from the main packagement system to reduce the needed ressources for database management.

Alternating build-dependencies! Build different versions against libssl-dev=0.9.6 and libssl-dev=0.9.7 in one run.

Smart file handling. Filesystem layers, dynamical replacement instead of cludges like Replaces and update-alternatives for non-executable stuff. Also smart symlink handling, this breakage with dangling manpage symlinks should not happen easily.

Concept for "post-dpkg-run actions" and other dpkg hooks, something for prelink, upx, etc. (s/dpkg/ups-install-step/).

Only installation kernels provided, including module series for each one. Kernel-package should be separated into a installation tool package which can be pre-depended by linux-kernel-image packages.

"diagnose" package that detects and fixes possible problems in relationships that have been discovered after the package has been released. Maybe a meta package containing only conditional dependencies.

Packages should have something common for the same functionality, eg. all ?libgalXZ provide a "Nickname: libgal". Just cosmetics, not a functionable model.

Rewrite ifupdown, it should have a more deterministic syntax for config files and rename the interfaces instead of using the current (a bit obscure) scheme.

And init, something about the init... new concept is needed. The need concept is nice, we should just have kind of priorisation, eg. running all scripts with nice -18 (or short sleeps between them, controllable by the user) when some script marked as "relevant user interaction entry" was started. The run levels must be kept for compatibility reasons. We could provide an update-rc.d wrapper and have a utility for managing non-packaged files. There are new init concepts such as simpleinit-msb and minit. A modern init should know about service dependencies, should allow parallel start of daemons and must be able to monitor arbitrary services (like old init does for gettys, but you can't disable single gettys except by switching the runlevel, can you?) for failures. Not necessarily as extensively as "monit" does (including port tests).

Finaly split -dev packages into -dev and -dev-static where later only contain the static library files. Most people never need them (but only headers) and can install the -dev packages.

More sane menu structure, see exiting efforts, Desktop...blabla... specs, etc.

Eduard Bloch on debian-devel pointed to this page, implicitely suggesting to put some ideas on "Debian for x86-64 (AMD Opteron)" here.

Extra ideas