Re: Upcoming Debian Releases
On Tue, 7 Jan 1997, B wrote:
> 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/01/06 09:57:04 bcwhite>
>
>
> 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
> ~~~~~~~~~~~~~~
> Sat, Feb 1, 1997 -- Deadline for objectives for Bo
>
> Mon, Feb 3, 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.
Bug age is not an appropriate designator of critical. Enhancement
requests, design flaws requiring the upstream maintainer's concent, and
bugs that are currently unfixable but have work arounds, should not be
concidered critical and "in the way" of a release.
With reguard to closing bugs, Brian knows my feelings about his, properly
named, "nag" messages. I prioritize my limited available time for Debian
based on the twice weekly publication of the outstanding bugs list. I find
obnoxious little messages like the "nag" to be just one more annoying
buzzing distraction.
>
> Thu, Feb 27, 1997 -- Bo will be frozen.
>
> Fri, Mar 28, 1997 -- Bo will be released.
>
>
> Thoughts
> ~~~~~~~~
> - When will Debian "officialy" be multi-architecture?
>
> - What should we do about packages that still have "critical" bugs at
> release time?
>
If these are identified early, and the maintainer, for one reason or
another, can't deal with it, we should call for volunteers to do the work.
As long as the fix is clear, it should be doable by release.
>
>
> -------------------------------------------------------------------------------
>
>
>
> Bo
> ~~
> * No bug reports older than 12 months at release time (bcwhite@verisim.com)
Please, not based on time?
> * Move config information from install scripts to "cfgtool" (???)
This seems to be "still in development", although I'm not involved in the
discussion. We should be certain that all necessary work can be performed
in the alotted time.
> * Shared libraries should provide ".shlibs" files (???)
> * 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 remaining "release critical" bugs (bcwhite@verisim.com)
> - Appropriate pkgs should call "install-mime" in postinst (bcwhite@verisim.com)
> - 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
> - Packages to call "install-menu" during postinst (joost@rulcmc.leidenuniv.nl)
> - 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]
> - new XFree86 3.2. stuff -- involves all packages using X
> - general "threading" policy (???) [6]
> - configuring so non-ASCII characters, etc. (???) [9]
> - All packages to be in new source format
This should probably be an asterisk item with higher priority. We,
supposidly targeted this one for the last release and only got about half
way there. This also might require some "floating" volunteers to get the
last few converted.
> - Make all web servers apply to the new standard, Bruce had released
> - Make all startup messages apply to the new standard
> - Use ttyS* devices instead of cua* devices (???) [10]
>
It is important that we make sure that all these targets are within range.
Some of the standards issues may be to large to reach completely for this
release (not that it shouldn't be worked on during that period) but,
again, others will know better than I.
> 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?
Although the majority of new users are severely intimidated by dselect.
This program has a non-trivial group of adherents who use it regularly to
manage their systems.
I would suggest (and I think several are following this tact) that we
build several alternatives to dselect, with the hope that one of them will
be more appropriate to "initial" installations by "novice" users.
This will be much easier if I can find the time to finish my
re-organization of dpkg's library into something that can be used by other
developers to provide dpkg capabilities to their own installation
programs. I will move it to the top of my priority list in an attempt to
get it out soon enough for useful entries during this development cycle.
However, this particular problem is so far reaching that we should not
expect to reach a "solution" in some short term "quick fix". We should
keep our goals "long term" on this issue.
>
>
> 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>
>
This can probably be provided in this cycle. Porting DoList to C with the
dpkg library along with the new dependency ordering program should provide
a quick installation of an arbitrary list of packages.
Later,
Dwarf
------------ --------------
aka Dale Scheetz Phone: 1 (904) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
------------ If you don't see what you want, just ask --------------
--
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: