All of these things (maybe except apt-i10n and the Newbie-Section) of
course apply to woody+1 or woody+2... But we should (or preferrably the
old and the new DPL together) start laying down a "Project-Wide" Roadmap
with important goals...
> first level: often used packages, max. 500-1000. This volume is used as
> primary target for dpkg/apt operation. It contains same data as
> Packages files handle now
I would consider adding the "flavours" then - one of the reasons we
switched to the package pool.
We probably should have "server", "mini", "desktop" flavours at least.
("graphics", "games" are other good flavours imho)
Basically we could make a flavour out of each section; just that a
package can be in multiple flavours.
Packages that are required by many flavours should go into a "base"
flavour. (ok, this will lead to something like splitting the Packages
file into sections... don't know if that actually will be good...)
Just what came into my mind right now.
When non-US is mostly merged this issue can be tackled easier... ;)
> Second level: names of additional packages and keywords (remember
> Erich's proposal)
I will redo that proposal; i've earned a few important additions which
will make it much more useful. Less keyword, more "tags".
Such as a "mature" tag with a numerical value, or a "free" tag (where
free:1.0 means dfsg-free, whereas free:1.2 might be PublicDomain ;)
> Thirth level: Rest of data, acompanying the second level.
We do have lot's of packages one will rarely install independant - such
as data packages for some applications or games. Who will install
tuxracer-data without installing tuxracer? The only gain is that the
game engine and the game data can be updated independantly.
> 2) dpkg's internal structure
> function could be replaced with an good database - saving space
> and increasing speed. <disclaimer>Yes, I propose to change important
> things. Yes, this is best done with a newer package format. No, I do not
Well, if i remember correctly, there was something called DPKGv2 - or
"Herring Package Management Library" around a few years ago.
What has happened to that one?
Yes, i think a database would be good. There has been a lot of research
how to operate on the databases fast and efficient.
Maybe we should have some dpkg-essential, employing ground-solid
algorithms (like dpkg does now) for installing the base system only, to
get the system into a useable state, and use faster-but-higher-level
algorithms and structures for handling the vast majority of packages?
XML would be nice, too. I don't like it, but it can ease writing and
support third party tools, suiteable for managing clusters etc.
> 3) Debconf's usage.
>
> The current debconf'isation and how it is often done, confuses more
> and more. Preinst and postinst scripts bomb you with thousands of
> questions before you even got a chance to have read the docs.
Right, and there were threads about debconf-abuse, too.
> We need an additional level for package's configuration state:
> "fine-configured". Only essential things are configured to get the
> package into the "configured" state. For all fine configuration, the
> user can invoke a frontend (GUI/TUI with list selection, or CLI like
> dpkg-reconfigure) and manage the rest.
I agree, there are lot's of things done with debconf that are not really
necessary to do at install-time. Like openldap for example - sure, the
openldap server will not be useable unless you fill it with some data -
but you can only add the admin account in debconf, the database will
have to be filled later anyway. So why not have the admin do the whole
openldap database creation later on?
> 4) Localisation: We need to provide better localisation. I am very
> disappointed about base-config, which is not localised while
> boot-floppies have good localisation support. We should have additional
> package attributes which can be replaced by apt, so specific packages can
> get higher Priority: depending on the country settings.
APT still hasn't got the support, although there have been apt-i18n
packages around for some time. That is BAD. One of our core utilities
still missing i18n is not good IMHO.
> 4.5) I suggest to use UTF8 as the default internal format. Unification
> at this point may prevent breakage letter.
That applies to Debian Changelogs, too. I recently came across some
changelog entry containing some Latin-1 characters. That's fine for me,
as i'm running Latin-1 but others might have serious problems with that.
Still some Developer Names do contain non-Ascii Characters...
We should push fast onto UTF-8 Compatibility in all our applications.
> 5) Configuration issues. The current stat is bad. Look at Knoppix, they
> manage to configure X for Debian without much user interaction. It is
> still not possible to make GPM and X to work together. Why cannot
> Branden and Zephaniah not work together?
AFAIK Debian XFree could autodetect most things, too. But just on intel.
The problem is that this would require some additional Pre-Depends:
mdetect (for Mouse detection, 80k)
read-edit (for Monitor detection, 80k)
Both are "Suggests:" by xserver-xfree86, unfortunately they usually are
not installed before xserver-xfree86; we could need some Pre-Suggests:
here...
On the GPM+X issue; i remember xserver-xfree86 showing /dev/gpmdata, i'm
not sure if this was maybe even the preselected value.
6) User Support
Spending lot's of time in #debian.de Channels and helping users with
FAQs and more difficult problems, i think we _really_ need to put some
very big user support and FAQ section on the debian.org webpage (and
make it more atttractive... People even tend to ask questions like
"where can i download debian CD images", seems like they didn't discover
the CD Link on the Web Page... not sure if we'll ever be able to get
these users to actually read, but i'm not happy being sometimes rude and
replying "go to the web page, everything is on there!")
The #debian.de People (well, mostly Alfie, weasel and Zomb) have put a
nice FAQ together in German at http://channel.debian.de/ which we
often do people point at, too.
The FAQ on debian.org is too well hidden (it took me three clicks to get
there... but newbies won't find it IMHO) and maybe too specific in some
issues, and already to big. It's more a Developer FAQ, not a Newbie FAQ.
We really should add a BIG newbie section.
Well, maybe there are good Debian-Newbie pages already, but i don't know
them, which isn't too good either...
The newbie page should for example recommend a good Debian book (and
probably a different one for each language ;), point to FAQ, point to
the bug tracking, point to Newsgroups and IRC and DebianPlanet.
And of course it should also point to the intro/about page.
currently, the main web page go into the Debian goals and history first;
the documentation page starts by pointing to the developer reference.
No wonder People don't start reading the docs here first...
Greetings,
Erich
Attachment:
pgpJqjVAg3nNp.pgp
Description: PGP signature