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 <[EMAIL PROTECTED]>
This document was last modified at Time-stamp: <97/06/02 21:25:35 bcwhite> *** *** *** Release of Bo is IMMANENT!!! *** *** *** *** Bo has undergone extensive testing and is now ready for release! *** *** No new packages are being allowed into "frozen". Uploads into *** *** "stable" must have an extremely good reason to do so and must be *** *** approved by the testing group before actually being installed. *** *** *** 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. A space means that the task has been completed. 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 or removing that package from the distribution because they are not fixed. Upcoming Dates ~~~~~~~~~~~~~~ July 1, 1997 Bugs older than 9 months will be marked as overdue. August 1, 1997 Bugs older than 8 months will be marked as overdue. September 1,'97 Bugs older than 7 months will be marked as overdue. Thoughts ~~~~~~~~ ------------------------------------------------------------------------------- Bo (Debian 1.3) ~~~~~~~~~~~~~~~ Fix all remaining "release critical" bugs ([EMAIL PROTECTED]) - Fix 63 remaining "overdue" bugs ([EMAIL PROTECTED]) Shadow password support ([EMAIL PROTECTED]) - Shared libraries should provide ".shlibs" files ([EMAIL PROTECTED]) - Appropriate pkgs should call "install-mime" in postinst ([EMAIL PROTECTED]) - 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 (???) Fix packages that break with new libc5.4 - Fix "installed size" entries in packages ([EMAIL PROTECTED]) - Improvements to 'dselect' ([EMAIL PROTECTED],[EMAIL PROTECTED]) [2] Move all shared libraries into "libs" ([EMAIL PROTECTED]) [4] Move interpreters out of "devel" ([EMAIL PROTECTED]) [4] Add support for resolutions beyond 1280x1024 to X config utility (???) [5] - Package grouping to simplify install ([EMAIL PROTECTED],[EMAIL PROTECTED]) general "threading" policy (???) [6] Fix pkgs referencing "/etc/site-start.el"([EMAIL PROTECTED])[7] - configuring so non-ASCII characters work (???) [9] Base 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] - Packages to call "update-menu" in postinst ([EMAIL PROTECTED]) [11] Hamm (Debian 2.0) ~~~~~~~~~~~~~~~~~ * All packages are in the new package format. * All packages in main distribution are compiled with libc6. * Fix packages currently depending on 'libc5-dev'. * Officially supports {i386,m68k,alpha,sparc} architectures (mips,ppc?). * No more dependencies on obsolete virtual packages (X11R6, elf-x11r6libs, ...). * No a.out executables anymore. * Remove "--force-overwrite" flag from dpkg defaults * Much improved dpkg/dselect. * Use PAM within authentication programs [13] * Link shared libs against other shared libs instead of static [14] * Official Debian logo chosen. - Move config information from install scripts to "cfgtool" (???) - Some sort of package-grouping mechanism for dselect - New run-level layout (???) [12] - No bug reports older than 9 months at release time ------------------------------------------------------------------------------- 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 4 - Here's a quick-n-dirty division of the current devel into the above classes: -- Lars Wirzenius <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 11 - Apart 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). -- [EMAIL PROTECTED] (joost witteveen) 12 - Has "Debian" defined any specific meaning to runlevels 2, 3, 4, and 5? For example RedHat puts everything in 3, everything but NFS stuff in 2, and starts xdm at run level 5 (as well as starting everything else). Run level 4 on the other hand is left totally open for the user. As far as I can tell, Debian seems to put everything that you install in 2, 3, 4, and 5, without differentiating between them. It seems like it would be nice to have distinct meanings for run levels, including one you get to make yourself, that Debian will never touch, so you don't have to worry about it being changed when you install new programs. -- Sam Ockman <[EMAIL PROTECTED]> Putting the nfs server in runlevels 3 and higher is something of an industry standard. To be more precise, rl 2 is intended to be for network client applications and rl 3 and higher for network server apps. I think it would be appropriate for Debian to follow suite. -- Brian N. Borg <[EMAIL PROTECTED]> 13 - PAM-mify at least the essential authentication programs (passwd, su,...) and preferably all programs that require authentication (POP clients, webservers, ...). <URL:http://parc.power.net/morgan/Linux-PAM/>. -- [EMAIL PROTECTED] (J.H.M.Dassen) From the FAQ <URL:http://parc.power.net/morgan/Linux-PAM/FAQ>: >Q3: Are there any distributions (of Linux) that come with PAM? > >YES. Currently, the only distributions that are shipped with PAM installed >are Red Hat Linux distributions. [...] >Caldera will be supporting PAM. > >Debian has made a commitment to support PAM in the future, there is a >debian package for it but applications have not been made available. > >Nothing is known of other distributions. 14 - Link shared libraries themselves against other shared libs, instead of including their code static (e.g. as current S-Lang already does); this can reduce memory use. -- [EMAIL PROTECTED] (J.H.M.Dassen) See H.J. Lu's "ELF: From The Programmer's Perspective" <URL:ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz> for details. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .