Debian    

Automate dpkg config file merging    

When dpkg is updating packages it sometimes runs into that config files have changed.

In that case it offers the user some options on how to deal with the updated config file, none of which is a merge.

There are actively maintained patches for adding a merge option (http://elonen.iki.fi/code/unofficial-debs/dpkg-merge/).

Somebody, *please* implement merge support for dpkg and get it accepted! It would close dpkg bug http://bugs.debian.org/120152 (from 2001) and ten others.

Further information

Improve logcheck    

Logcheck has become the de-facto log monitoring tool on Debian, even though it's quite in a bad condition. A feature desperately needed is the interpolation of rule files with macros. A proof-of-concept already exists, but it needs to be implemented.

Furthermore, a tagging system would make logcheck usable again.

Further information

Convert systems into fully-encrypted systems    

Take your USB-stick (or a CD-R) as primary boot medium and loader. Put
on it a kernel and a initrd that boots, and detects your fully
encrypted harddrive. The kernel/initrd sets up dmcrypt/cryptsetup and
unlocks your harddrive. Now it calls kexec and changes into the real
system on the harddive and boots your system.

This way _everyting_ on the harddrive can be encrypted. It also has
the advantage your running system doesn't need to know anything about
it being encrypted at boot time. And things like kernelupgrades (mind
update-initramfs) also don't have to bother with anything crypto
related.

It would be nice to have such a really small kernel/initrd combo for
your USB-stick and a system that can handle it being booted vie kexec.

Further information

Make copyright files machine-readable    

There is a proposal to make the copyright files machine-parsable. To make real use of this, there should be a program to check these files. This program should at least be able to:

* Provide the license of a given file in the tree.
* Check that every file in the tree has a license. This should somehow ignore generated files. The easiest way to do this might be to require the clean target in rules to remove all of them. There is some discussion about this, though.

Further information

Single-entry bug reporting    

There are different places visible to an end-user that are used to
report bugs: reportbug if installed, but it is not very visible; GNOME
report tool is somewhere in the menu; KDE has something
similar; some applications have their own in the menu.

Ideally there would be a wrapper that will guide the user to the right tool by
asking questions (reportbug(-ng) in most cases), and launch it. so for the
end-user there is only one entry point for bug reporting.

Include build environment information in packages    

Provide a script that collect info on the build environment at compile time eg: date of the build - compiler version - glibc version - kernel version - ....
and insert this info in the final deb package. This can be useful for sanity check and for statistical purpose. The implementation could be prototype-like.

menu transition to XDG *.desktop menu system    

Given how the XDG format is derivated from Debian's own menu and has become
standard accross the board on a wide variety of desktop environments and window
managers, migrating Debian's menu system to XDG would be extremely desirable.

Further information

Use linux-libre    

The official linux kernel at kernel.org is non-free. But there is a fork of the kernel called linux-libre which takes out the non-free blobs out of the current official kernel. I don't know why nothing is being done about this issue, because this is an actual GPL violation that's happening now.

Further information

Design a proper multi-arch implementation    

Multi-arch has been lingering on Debian for years. There are open issues, but most people have lost oversight.

Collect the information you can find, design an improved system that addresses all problems that are on the table, and possibly even a crude reference implementation!

Samba User Account Import Behavior    

During installation of the package, all user accounts are imported from the local database. This may or may not be desirable from the installers point of view, but the package's current policy is to import them anyways, which means www-data and other accounts show up when looking at NT domain accounts. The concern is that a windows admin will not recognize the need for these accounts and attempt to remove them, etc. The counter-argument is that they should be included.

To resolve this perceived issue, during installation the package should prompt with a question "Include user accounts that are for services?" or something similar, giving the installer a choice in the matter. This will occur at a normal verbosity level; at a higher level (all automatic) it will default to its existing behavior. If the installer chooses to not include these accounts, then all accounts with a uid < 1000 will be omitted during import. This places more power into the hands of the installer (who is ultimately the end-user) and does not break any existing conventions in the process.

Further information

Installer License Preference    

Look at the possibility of having the initial installation guided by license preference. The idea is that the installer is presented with a list of licenses that they can choose from. After they have selected the licenses that are appropriate for them, it acts as a filter during the installation process and omits/includes packages based on those license selections. In a commercial "I-don't-care-just-install-it" setting, all the licenses - including proprietary ones - may be selected and allow for a larger software base. In a stricter FOSS-style environment, maybe only BSD/GPL/Artisitic licenses are selected, and only those packages that match are available. This would be a very low priority question that would not affect a normal installation process unless the installer increased the verbosity of the installation.

Out-Of-Package Policy Retention    

When performing a dist-upgrade, packages should attempt to match and re-use existing policies. This is not always the case - i.e. prior versions of Samba installations would omit uid < 1000 but newer versions do not. If the original setup followed that policy, and there is a policy change, then the package should obey the original policy decision. This is different from package remembering answers to prior installations - this is more along the lines of packages recording the net policy at the point of installation so that future packages will continue to behave in that manner.