Upcoming Debian Releases
The following message is a list of items to be completed for the upcoming
releases of Debian GNU/Linux. If something is missing, incorrect, or you want
to take responsibility for one or more items, please send email to:
Brian White <bcwhite@verisim.com>
This document was last modified at Time-stamp: <97/04/05 18:26:47 bcwhite>
***
*** Bo is due to be released at the end of April. Please use that system
*** as exclusively as possible in order that we get the most amount of
*** testing done.
***
*** If you'd like to become part of the official testing group, please
*** contact Dale Scheetz <dwarf@polaris.net>.
***
If you're replying about some of the ideas mentioned in this document, it is
often wise to change the subject to reflect that idea. This helps target
those people who are most likely to partake in discussions about it.
For each upcoming release, the name of the task and the person who has claimed
responsibility for it (or "???" if nobody) is listed. An asterisk (*) in front
means the job has yet to be completed and must be done before that release can
be made "stable". A dash (-) in front means it has not yet been completed,
but if not completed in time will just be pushed to the next release.
Footnotes are indicated by "[n]" and give more information on that item.
If you know of packages that do not conform to any of these tasks, please
report it as a bug against those packages. If that task is marked as critical
(i.e. with an asterisk "*"), then please let me know and I will mark the bug
as critical.
Critical bugs are those that you would seriously consider delaying the
upcoming release because they are not fixed.
Upcoming Dates
~~~~~~~~~~~~~~
April 28, 1997 Bo will be released
June 1, 1997 Bugs older than 6 months will be marked as overdue (will be at
least 9 months old by the time Hamm is released).
Thoughts
~~~~~~~~
-------------------------------------------------------------------------------
Bo (Debian 1.3)
~~~~~~~~~~~~~~~
* Shared libraries should provide ".shlibs" files (bcwhite@verisim.com)
Move all shared libraries into "libs" (maor@ece.utexas.edu) [4]
Move interpreters out of "devel" (maor@ece.utexas.edu) [4]
Shadow password support (maor@ece.utexas.edu)
* Fix pkgs referencing "/etc/site-start.el"(Frederic.Lepied@sugix.frmug.org)[7]
* Fix 4 remaining "release critical" bugs (bcwhite@verisim.com)
* Fix 107 remaining "overdue" bugs (bcwhite@verisim.com)
- Appropriate pkgs should call "install-mime" in postinst (bcwhite@verisim.com)
- Convert remaining a.out packages (???)
Boot disks should contain drivers for more systems/cards (???)
Integration of modules, kernel, boot-floppies, & pcmcia (???) [1]
- Include the multi-thread support patch for the Objective-C runtime lib (???)
Add support for resolutions beyond 1280x1024 to X config utility (???) [5]
- Fix packages that break with new libc5.4
- Packages to call "update-menu" in postinst (joost@rulcmc.leidenuniv.nl) [11]
- Fix "installed size" entries in packages (bcwhite@verisim.com)
- Improvements to 'dselect' (cjf@netaxs.com,dystan@netaxs.com) [2]
- Package grouping to simplify install (cjf@netaxs.com,dystan@netaxs.com)
- 'dselect' to determine what to install/remove (???) [3]
general "threading" policy (???) [6]
- configuring so non-ASCII characters work (???) [9]
- All packages to be in new source format
- Make all web servers apply to /usr/doc/debmake/webstandard-3.0
- Make all startup messages apply to the new standard
- Use ttyS* devices instead of cua* devices (???) [10]
hamm
~~~~
* No bug reports older than 9 months at release time
Decicision about stable/unstable "contrib" and "non-free"
* Officially multi-architecture.
- Move config information from install scripts to "cfgtool" (???)
- Some sort of package-grouping mechanism for dselect
-------------------------------------------------------------------------------
Footnotes
~~~~~~~~~
1 - Friday I used the boot floppies in the rex tree and I could load any
modules (NFS being the show stopper). In the Linux Journal review of
Debian (Nov Issue), explictly mentions this problem with 1.1 and it
hasn't been solved yet :( -- Chris Fearnley <cjf@netaxs.com>
2 - Dselect is our number one public relations problem. It's infelicities
lead others to believe that the package management has flaws and some
can't even get through it. One issue that was raised in a bug report was
to NOT pop up the help screen everytime dselect notices a
dependency/recommendation/conflict problem. I concur. I remember that
that bug report suggested that dselect should not pop up the conflict
resolution manager with its suggestions. I now disagree with that. The
feedback that Debian /cares/ about you not breaking your system (and
offers to suggest a resolution) is more important than the small
frustration in a case one was about to select those packages anyway.
Finally, I believe that dselect is too complex for a program that will
only be used by novices once every six months! Perhaps having only
options for
+ install, upgrade
- unselect, ignore (NOT current semantics so maybe a bad idea?)
r remove from system
And some way to override defaults? Would this be sufficient?
3 - I.e.: say I just want to install a package for a single library-- but I
also want the developer version and the static version... As it stands, I
can either su to root, find the packages and 'dpkg -I' or start dselect,
select the packages, install and wait *forever* as dselect does it's
thing. Instead of having dselect check every single package-- would it
be possible to have a "fast" mode that just installs/uninstalls what the
user selected? -- Bill Bumgarner <bbum@friday.com>
4 - Here's a quick-n-dirty division of the current devel into the above
classes: -- Lars Wirzenius <liw@iki.fi>
libs:
CGI-modules blt id-utils libc4 libelf libg++27 libident
libobjects libpam libwww-perl tcl74 tcl75 tclX tk40 tk41
slang-lib
interpreters:
expect gcl guile intercal j1 perl perl-suid perl-tk
postgres95 python python-base python-curses python-dev
python-doc python-examples python-gdbm python-misc
python-mpz python-net python-stdwin python-tk gclinfo
postgres95-docs
devel:
autoconf automake bin86 binutils bison byacc c2man
cflow dchanges ddd-smotif dejagnu dist dld dlltools
electric-fence flex ftnchek gcc gdb gettext gmp gnat
ilu indent libc4-dev libc5-dbg libc5-dev libc5-pic
libdb1-dev libelf-dev libgdbm1-dev libreadline2-dev
make ncurses3.0-dev ncurses3.0-pic p2c perl-debug pmake
ratfor77 slang-devel strace tcl74-dev tcl75-dev
tk40-dev tk41-dev xxgdb glibcdoc cpp m4 cvs rcs
5 - There is a brand new config utility in the XFree86 3.2 release which will
be release end of October (their codefreeze was some time ago). All
efforts put into any package from the standrad X packages (xbase,
xdevel,xfnt*,...) should rather go into providing the new packages.
Note I do not say that we should have this ready for 1.2 (though I hope
we have it very soon), but fixing things in obsolete packages isn't how
we should spend our time.
6 - All libraries are to be compiled with -D_REENTRANT
7 - These packages shouldn't modify the site-start.el file anymore and
instead put a file in /etc/emacs/site-start.d with the naming convention
XYpackage.el where XY is the scheduling init level.
-- Frederic Lepied <Frederic.Lepied@sugix.frmug.org>
9 - One of the things that most people outside the US and UK have to deal
with is configuring everything so that non-ASCII characters and other
locale specific stuff works right. For example, bash needs a ~/.inputrc
so that you write åäö on the command line, instead of getting
beeps. Emacs needs some other stuff. -- Lars Wirzenius <liw@iki.fi>
10 - /dev/ttySxx devices are fully POSIX-compliant TTY devices. If you are
only going to be using one set of tty devices, you should be using
/dev/ttySxx.
/dev/cuaXX devices are different from /dev/ttySXX in two ways --- first
of all, they will allow you to open the device even if CLOCAL is not set
and the O_NONBLOCK flag was not given to the open device. This allows
programs that don't use the POSIX-mondated interface for opening
/dev/ttySxx devices to be able to use /dev/cuaXX to make outgoing phone
calls on their modem (cu stands for "callout", and is taken from SunOS).
The second way in which /dev/cuaXX differs from /dev/ttySXX is that if
they are used, they will trigger a simplistic kernel-based locking
scheme: If /dev/ttySXX is opened by one or more processes, then an
attempt to open /dev/cuaXX will return EAGAIN. If /dev/cuaXX is opened
by one or more processes, then an attempt to open /dev/ttySXX will result
the open blocking until /dev/cuaXX is closed, and the carrier detect line
goes high.
While this will allow for simple lockouts between a user using a modem
for callout and a getty listening on the line for logins, it doesn't work
if you need to arbitrate between multiple programs wanting to do dialout
--- for example, users wanting to do dialout and UUCP.
I originally implemented the cuaXX/ttySXX lockout mechanism back before
FSSTND established a standard convention for the use of tty lock files.
Now that it's there, people should use the tty lock files and not try
using /dev/cuaXX. The only reason why /dev/cuaXX hasn't disappeared yet
is for backwards compatibility reasons.
-- Theodore Ts'o <tytso@mit.edu>
11 - Appart from the update-menus call in the packages that want to register
their applications with the menu-system, it would also be nice if more
window managers than at present would include a /etc/menu-methods/ script
(for all[1] window managers I've put example scripts in the menu package
example dir), and a little bit of postinst/postrm stuff (example in the
README). This would then allow the update-menus programme to actually
generate the "system.fvwm*rc" files for the specific window managers.
(note that those window managers should *not* depend on "menu", as wheter
or not to install the package should be up to the local system admin).
-- joost@rulcmc.leidenuniv.nl (joost witteveen)
Reply to: