[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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/06/20 10:04:42 bcwhite>


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
~~~~~~~~~~~~~~
June 30, 1997	Bug reports against all non-libc6 packages.
July 1, 1997    Bugs older than 9 months will be marked as overdue.
July 15, 1997	All uploaded libraries must depend on libc6.
July 31, 1997	All uploaded packages must depend on libc6.
August 1, 1997  Bugs older than 8 months will be marked as overdue.
August 31, 1997	All packages depending on libc[45] will be moved to contrib.
September 1,'97 Bugs older than 7 months will be marked as overdue.



Thoughts
~~~~~~~~



-------------------------------------------------------------------------------



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.
- Fix remaining "overdue" bugs (bcwhite@verisim.com)
- Appropriate pkgs should call "install-mime" in postinst (bcwhite@verisim.com)
- Convert remaining a.out packages (???)
- configuring so non-ASCII characters work (???) [9]
- Make all web servers apply to Web Standard (cf. Policy Manual)
- Make all startup messages apply to the new standard
- Use ttyS* devices instead of cua* devices (???) [10]
- Packages to call "update-menu" in postinst (joost@rulcmc.leidenuniv.nl) [11]
- 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
~~~~~~~~~

 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 - 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).
        -- joost@rulcmc.leidenuniv.nl (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 <ockman@cs.stanford.edu>

     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 <bborg@iaxs.net>



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/>.
         -- jdassen@wi.leidenuniv.nl (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.  -- jdassen@wi.leidenuniv.nl (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
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: