Re: Bug#19920: Packages Optional, should be Extra
On Wed, Mar 18, 1998 at 05:26:42PM -0600, Manoj Srivastava wrote:
> Hi,
> In the sprit of submitting bugs that affect a large number of
> packages, this should be
>
> a) discussed on the mailing list,
> b) have bugs filed against all packages so that peole may edit the
> control files.
>
> I definitely think this should not be acted on out of hand.
>
> Also, I think it is a bad idea to file bugs based on "An old
> version I tried was buggy, I have not seen the new versions, but let
> us act on the old buggy behaviour anyway.". Try Arena before you file
> a bug.
I agree strongly. I have looked at the first half of the long list, and I
feel that Ian has decided on a *very* subjective rational, and I will comment
on some of them below in detail.
I gave up half way through. I see three categories:
1) packages that require additional hardware or conflict with the rest of
the system. Those have to go to extra. This is the current interpretation of
extra in the policy.
2) packages that may not be attractive for "most people" whatever most
people may be like. See below.
3) packages that are old, outdated (online magazines) or buggy.
Those packages should either be fixed or removed from the distribution.
All packages have to conform the high standard of quality. Extra is no
section for trash.
I appreciate Ian's afford to clean out "optional", but this requires more
than putting random packages to "extra". Packages that fall under the scope
of 1) above should be moved to extra ASAP. But packages that are not "for
many people" should still be in optional until a better solution is found.
Here are two possible solutions:
a) Wait for de*ty's capability to make predefined bunches of package
selection, so it is easier for users to install "just a mailer".
b) Make an additional section either between standard and optional or
between optional and extra. (Suggestion: "preferred" or "extra", where old
extra will be renamed to "special" or so).
I don't want to decide which package should be optional and which should
belong to the other category. I would prefer to leave it as it is.
> Ian> It is my opinion that the following Optional packages should be
> Ian> extra, because they are only useful to people with special
> Ian> requirements or hardware. Perhaps some discussion needs to be
> Ian> had with the package maintainers.
> Ian> Package: arena Description: an HTML 3.0 compliant WWW browser for
> Ian> X (because it is very buggy, at least last time I used it.
> Ian> Perhaps it is better now)
As Manoj already said, this is no rationale to move it to extra. Bugs are
there to be fixed.
> Ian> Package: bash-builtins Description: Bash loadable builtins -
> Ian> headers & examples
What are the special requirements here?
> Ian> Package: bulkmail Description: Speed up delivery of e-mail to
> Ian> large numbers of recipients.
I agree that you need a special attitude to use this effectively ?!
> Ian> Package: cern-httpd Description: The CERN HTTP (World-Wide Web)
> Ian> server (We should only install one webserver by `default' even in
> Ian> a large system, and it should be apache.)
>
> Ian> Package: boa Description: Lightweight and High Performance
> Ian> WebServer (We should only install one webserver by `default' even
> Ian> in a large system, and it should be apache.)
>
> Ian> Package: dhttpd Description: Minimal secure webserver. No cgi-bin
> Ian> support! (We should only install one webserver by `default' even
> Ian> in a large system, and it should be apache.)
>
> Ian> Package: ncsa Description: Small featureless NCSA Webserver (We
> Ian> should only install one webserver by `default' even in a large
> Ian> system, and it should be apache.)
>
> Ian> Package: wn Description: Secure and efficient http server with
> Ian> advanced features. (We should only install one webserver by
> Ian> `default' even in a large system, and it should be apache.)
I think it may make sense to be able to install several webservers (on other
ports, for example). We should work on this, so they can be installed
and configured concurrently. Otherwise you also have to move other MTA's
also, but...
> Ian> Package: exim Description: Exim Mailer Conflicts:
> Ian> mail-transport-agent (But Smail is Important.)
>
> Ian> Package: exim-doc Description: Exim MTA info documentation
>
> Ian> Package: eximon Description: X-windows monitor for the exim mail
> Ian> transport agent.
As probably exim will make it to be Debian standard mailer, this is a
strange decision. I don't know why exim conflicts and the other mta's do
not, but certainly the better solution is either to make smail optional or
to replace smail by exim ;)
> Ian> Package: cfingerd Description: Configurable and secure finger
> Ian> daemon (This daemon is not so secure; its documentation claims
> Ian> that syntax errors in the config file can cause coredumps and the
> Ian> author seems unworried. This is not suitable for use unless you
> Ian> know what you're doing.)
(*)
Then this should be fixed. Are bugs a reason to downgrade the section? *All*
packages in the Debian main distribution must compare to the same standard
of quality. If cfingerd is broken, it has to be fixed or removed from the
distribution.
> Ian> Package: chimera2 Description: Web browser for X ... This is an
> Ian> alpha-test version; some of the rendering routines are buggy.
see above (*).
> Ian> Package: debmake Description: Debianizing Tool and automated
> Ian> binary generation (We should be deprecating debmake.)
Mmmmh. Also I don't like debmake as most of us, I feel a bit uneasy by this.
Probably it is better to remove it ;)
> Ian> Package: devscripts Description: Scripts to make the life of a
> Ian> Debian Package maintainer easier. (Christoph scripts. Contains
> Ian> namespace pollution, strange setuid binaries, &c.)
I found "build" very useful. Maybe build shoulb be in dpkg-dev, under a
different name? Then the package could be removed, IMHO.
> Ian> Package: display-dhammapada Description: Displays verse from
> Ian> Dhammapada. (Seems obscure to me ...)
Then please move the bible* packages, too. I find your rational funny, too.
> Ian> Package: echo-linux Description: French on-line magazine "L'Echo
> Ian> de Linux"
If the information is outdated, the package should probably be removed at
all... but who wants to read it and check it?
> Ian> Package: elisp-manual Description: Emacs Lisp Reference Manual
>
> Ian> Package: emacs-lisp-intro Description: Programming in Emacs Lisp:
> Ian> An Introduction
Could you please give a rationale for this? Beside a certain amount of
intellectual capabilities, there are no special hardware you need to read
and understand a manual. I don't think learning of a new language should be
depreciated. Instead, I wish we had manuals and tutorials for all languages!
> Ian> Package: gap Description: gap is a system for computational
> Ian> discrete algebra. installed-size: 24180
Why should this be extra?
> Ian> Package: gdkimlib-dev Description: Library that allows to display
> Ian> images within gdk/gtk
>
> Ian> Package: gdkimlib0 Description: Library that allows to display
> Ian> images within gdk/gtk (That's all of the descriptions, so I'm
> Ian> guessing)
Someone already sdaid something about them. They belong to the Gtk project
and shoud be in optional.
> Ian> Package: gltt-bin Description: sample programs using gltt (gltt
> Ian> is apparently `library to read and draw TrueType fonts in OpenGL
> Ian> programs' and should be Optional because something depends on
> Ian> it.)
I don't understand what you mean with "something depends on it").
> Ian> Package: hypermail Description: Create HTML archives of mailing
> Ian> lists (Most people don't run mailing lists.)
Most people don't use package <X> is actually no reason to put <X> in extra.
This is not my current understanding of extra, as I read it in the policy
manual.
> Ian> Package: journal-dev Description: Scripts to help building an
> Ian> on-line magazine
>
> Ian> Package: kernel-source-2.0.33 Description: Linux kernel
> Ian> source. (et al. Source code distributed as a .deb should not be
> Ian> installed unless the user knows they want it.)
This is a joke, isn't it? I would agree with other source packages, but the
kernel? I think it is essential for every Linux system to recompile the
kernel occasionally. The default kernel is too slow at startup.
> Ian> Package: libwine-dev Description: WINdows Emulator (Development
> Ian> Files)
see below, at wine.
> Ian> Package: libwine0.0.971116 Description: WINdows Emulator
> Ian> (Library)
>
> Ian> Package: libwmaker0 Description: Shared libraries for WindowMaker
> Ian> aware applications.
>
> Ian> Package: libwmaker0-dev Description: Static libraries and headers
> Ian> for WindowMaker applications.
>
> Ian> Package: libwraster0 Description: Shared libraries of WindowMaker
> Ian> rasterizer.
>
> Ian> Package: libwraster0-dev Description: Static libraries and
> Ian> headers of WindowMaker rasterizer.
>
> Ian> Package: mandelspawn Description: a distributed processing
> Ian> Mandelbrot program for X (You need many computers.)
I think this can alo work on a single computer. Did you check this? Maybe
even over internet.
> Ian> Package: mhonarc Description: Mail to HTML converter (Another
> Ian> list archiver.)
I don't think that list archiver should be in extra.
> Ian> Package: nas Description: The Network Audio System (NAS). (I
> Ian> _believe_ this thing still takes over /dev/audio et al if you
> Ian> install it, preventing other programs from working.)
Other programs *should* use it. It takes over /dev/audio when it runs,
because it is a server. Because most programs that use sound have their own
small server, only one sound program can run at once. With the rational you
gave, *all* packages that have sound should be extra, because they are
preventing each other. NAS is providing a solution for this problem if you
build the programs to use it (but then you get other problems, as NAS is
slower than direct access).
> Ian> Package: wine Description: WINdows Emulator (Binary Emulator)
>
> Ian> Package: wine-doc Description: WINdows Emulator (Documentation)
I don't think that emulators should be extra, just because you need software
for other platforms to use them. Hmmm.
--
"Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@
Marcus Brinkmann http://www.debian.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: