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

Upcoming Debian Releases [auto-post]

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:  <96/11/04 23:08:30 bcwhite>

***                                                                       ***
***  Rex has been officially frozen! Guy Maor <maor@ece.utexas.edu> will  ***
***  be making the necessary changes to 'master' and these should become  ***
***  visible on 'ftp.debian.org' and other mirrors in the near future.    ***
***                                                                       ***
***  Please do not upload packages destined specifically for 'bo' until   ***
***  these changes become visible.                                        ***
***                                                                       ***

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.

Upcoming Dates
Wed, Nov 27, 1996 -- Rex will be released as "Debian 1.2".  This should allow
                     it to get out to the mirror sites by December 1st.

Mon, Jan  6, 1997 -- Bugs older than 10 months (will be 12 months by release)
                     will be marked as critical.  People might want to start
                     fixing/closing/forwarding these now to avoid the eventual
                     "nag" messages.

Thu, Jan 30, 1997 -- Bo will be frozen.

Tue, Feb 25, 1997 -- Bo will be released.

- When will Debian "officialy" be multi-architecture?

- What should we do about packages that still have "critical" bugs at
  release time?


Rex  (aka "Debian 1.2")
* Shared libraries should provide ".shlibs" files (???)
* Boot disk & kernel packages should be v2.0.24 or later (???)
* Move all shared libraries into "libs" (maor@ece.utexas.edu)  [4]
* Move interpreters out of "devel" (maor@ece.utexas.edu)  [4]
* Shadow password support (marekm@i17linuxb.ists.pwr.wroc.pl)
* Fix pkgs referencing "/etc/site-start.el"(Frederic.Lepied@sugix.frmug.org)[7]
* Fix 28 remaining "release critical" bugs (bcwhite@verisim.com)
- Appropriate packages should call "install-mime" during postinst
- Ask for the user's keyboard type _first_ (vincent@waw.com)  [8]
- 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

* No bug reports older than 12 months at release time (bcwhite@verisim.com)
* Move config information from install scripts to "cfgtool" (???)
- Packages to call "install-menu" during postinst (joost@rulcmc.leidenuniv.nl)
- Fix "installed size" entries in packages (bcwhite@verisim.com)
- Improvements to 'dselect' (???)  [2]
- Package grouping to simplify install (???)
- 'dselect' to determine what to install/remove (???) [3]
- new XFree86 3.2. stuff -- involves all packages using X
- general "threading" policy (???)  [6]

* No bug reports older than 9 months at release time



 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>

            CGI-modules blt id-utils libc4 libelf libg++27 libident
            libobjects libpam libwww-perl tcl74 tcl75 tclX tk40 tk41

            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

            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 - It's a real pain when you want to do thread programming right now,
     especially since things like X haven't been compiled with the thread safe
     headers (getc and putc, etc.).  We had to recompile some of X ourselves
     in order to make things even somewhat stable.
       -- Rob Browning <osiris@cs.utexas.edu>

     There was some talk about threads and Debian a while back, and I just
     wanted to see what the current sentiment was.  I know that pthreads is
     part of libc, but it's not (as I recall) currently provided with the
     system.  What's more, it has some outstanding bugs, and at least last
     time I checked, the version that comes with libc is a bit behind the
     latest release.

     Anyway, the other major contender seems to be LinuxThreads.  It's a
     kernel level implementation so you don't need all the glue code that
     pthreads has, and it supports multiple CPU's.  It also seems to be under
     more active development.

     Anyway, I just wanted to see if we had any general plans toward making
     Debian thread safe.  Aside from just picking a library, it would also
     mean (at least with pthreads, I'm not sure about LinuxThreads),
     recompiling other code (especially the X libraries) with the thread safe
     headers (i.e. getc and putc are normally thread hostile macros).

 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>

 8 - Of course it doesn't change anything for people using a US keyboard, but
     it would be a good step forward in conviviality for people having a
     French keyboard (At least).

     For those who don't see what I mean, typing "!dev!hdq&" instead of
     "/dev/hda1" is not fun... _(:

     NB: To tell the truth, that was the biggest problem I had, each time I
     installed Debian... _(:  -- Vincent Renardias <vincent@waw.com>

TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com

Reply to: