Discussion:
RFC: cups as "default" printing system for lenny?
Steve Langasek
2007-11-11 02:17:22 UTC
Permalink
A few years back, Samba upstream began using CUPS as the default printing
system whenever CUPS support was enabled. At the time, cupsys was Priority:
optional, and lpr as the standard Unix printing interface was Priority:
standard (or higher), so I patched the Samba packages in Debian to default
to BSD printing instead of CUPS.

Today the circumstances have changed. It seems that lpr was demoted to
optional sometime before the etch release, putting it on equal footing with
cupsys in that regard, and CUPS itself has IME improved markedly since the
time that decision was made (I'm personally still not fond of the
implementation, but at least it does a better job of talking to printers for
me :). So I have two questions:

- Is there any remaining reason why the Samba maintainers shouldn't drop
this patch, switching to CUPS as the default print system?
- Should we consider raising the priority of cupsys to standard, to take the
place of lpr as an available-by-default printing system on stock installs?

Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
***@debian.org http://www.debian.org/
Russ Allbery
2007-11-11 05:42:52 UTC
Permalink
Post by Steve Langasek
- Should we consider raising the priority of cupsys to standard, to take the
place of lpr as an available-by-default printing system on stock installs?
The last time I looked at CUPS, it was massively more complicated than lpr
and involved dubious things like running daemons that listened on network
ports for user configuration. Is that still the case?

Also, do we really need *any* printing system as priority: standard? It's
not clear to me that printing is still really part of a standard Unix
installation, even for desktop users (and it definitely isn't for
servers).
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Joey Hess
2007-11-11 06:05:36 UTC
Permalink
lpr's standard priority nonwithstanding, CUPS has been the default print
system in Debian -- if you select the desktop or print server tasks --
for at least the last two releases. This is why popcon shows 5000 lpr
installations to 45000 cupsys installations.

Yes, it would make more sense for samba to default to CUPS, if there's
some reason it can't probe/support both, and if it can't use the generic
lpr interface also provided by cupsys.

Yes, there's no reason to have any printing system at standard priority.
A full CUPS install with all the PPDs and such would bloat standard
enormously. Just making cupsys standard would perhaps allow spooling to
remote printers from the command line, but not much else. d-i makes it
easy enough to get CUPS installed.
--
see shy jo
Steve Langasek
2007-11-12 02:12:06 UTC
Permalink
Post by Joey Hess
Yes, it would make more sense for samba to default to CUPS, if there's
some reason it can't probe/support both,
Well, because there's no code written to do this, and anyway supporting both
at the same time would likely be messy and result in duplicate queues.
(Note that one of the reasons Samba needs to know what print system is in
use is in order to export the list of available queues over SMB if
configured to do so.)
Post by Joey Hess
and if it can't use the generic lpr interface also provided by cupsys.
The cupsys lpr interface is only available with the cupsys-bsd package,
which is Priority: extra and is not likely to be installed unless
specifically requested. So if CUPS is preferred, it's more straightforward
to just use the native CUPS support.

I'll make this change to the Samba packages for lenny, after verifying
whether any special handling is needed for transitioning.
Post by Joey Hess
Yes, there's no reason to have any printing system at standard priority.
A full CUPS install with all the PPDs and such would bloat standard
enormously.
I don't agree that making CUPS standard implies also making all of the PPDs
standard (AFAICS cupsys only Recommends foomatic-filters and doesn't depend
on any PPDs at all), but I'm not bothered if CUPS doesn't become standard
either; just thought the question was worth asking.
Post by Joey Hess
Just making cupsys standard would perhaps allow spooling to remote
printers from the command line, but not much else. d-i makes it easy
enough to get CUPS installed.
Indeed, I seem to have it already installed even in places where I didn't
want it. ;)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
***@debian.org http://www.debian.org/
Bernd Zeimetz
2007-11-11 06:14:29 UTC
Permalink
Post by Russ Allbery
Also, do we really need *any* printing system as priority: standard? It's
not clear to me that printing is still really part of a standard Unix
installation, even for desktop users (and it definitely isn't for
servers).
I'd guess most Desktop installations have a printing system installed,
just because you need it if you want to print. Cups works very well for
that these days as it is able to detect the printers which are shared by
other cups installations in the network. If you're not 'living' in a
network with an administrated cups server, adding/configuring printers
is - for example - possible from the KDE Control Center. You can still
configure cups on http://localhost:631 - but as far as I can tell
there's no need to use the webinterface anymore.

For servers a printing system doesn't make sense, especially if it does
more than listening on a local port. As far as I know the default
setting of cups is to broadcast, looking for other printers in all
networks. I'd definitely want to avoid that on a server.

Not sure if anybody is still using the old BSD printing stuff - at least
I can't see any reason why it should have a higher priority than optional.


Cheers,

Bernd
--
Bernd Zeimetz
<***@bzed.de> <http://bzed.de/>
Russ Allbery
2007-11-11 06:20:20 UTC
Permalink
Post by Bernd Zeimetz
Not sure if anybody is still using the old BSD printing stuff - at least
I can't see any reason why it should have a higher priority than optional.
I am. It's simple and it works, and CUPS seems ridiculously bloated for
the only printing need I have (printing PostScript files to a network
printer).

However, I can certainly agree that it's a difficult choice for the
average user for a locally attached printer due to the difficulty of
configuration and handling of printer drivers.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Bernd Zeimetz
2007-11-11 08:19:04 UTC
Permalink
Post by Russ Allbery
Post by Bernd Zeimetz
Not sure if anybody is still using the old BSD printing stuff - at least
I can't see any reason why it should have a higher priority than optional.
I am. It's simple and it works, and CUPS seems ridiculously bloated for
the only printing need I have (printing PostScript files to a network
printer).
In theory that's all I need, too - and our printers support it. But they
also support to print from 6 different trays and a _lot_ of other
settings - and that's the point where you need a ppd file. Luckily OSX
uses cups, too, so often you're able to get good ppds from the producer,
at least for the more expensive models. Using them was very painless so
far - it just works.
--
Bernd Zeimetz
<***@bzed.de> <http://bzed.de/>
Manoj Srivastava
2007-11-11 07:26:25 UTC
Permalink
Post by Russ Allbery
Also, do we really need *any* printing system as priority: standard?
It's not clear to me that printing is still really part of a standard
Unix installation, even for desktop users (and it definitely isn't for
servers).
Way back when, “standard” was defined as stuff that an old UNIX
hand would say “WTF happened to that?” if it is not present on a
default install. While I am unsure of this definition of standard still
holds, but as an old UNIX hand I can say that if I am on a UNIX like
machine, and I can't just say lpr foo.txt and have it printed on the
default printer, I would find the system deficient and un-UNIX like.

How the printing occurs is not significant, as long as it can.

manoj
--
Why does a ship carry cargo and a truck carry shipments?
Manoj Srivastava <***@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Bernd Zeimetz
2007-11-11 08:21:46 UTC
Permalink
Post by Manoj Srivastava
Way back when, “standard” was defined as stuff that an old UNIX
hand would say “WTF happened to that?” if it is not present on a
default install. While I am unsure of this definition of standard still
holds, but as an old UNIX hand I can say that if I am on a UNIX like
machine, and I can't just say lpr foo.txt and have it printed on the
default printer, I would find the system deficient and un-UNIX like.
That works well with cups if you have the cupsys-bsd package installed.
--
Bernd Zeimetz
<***@bzed.de> <http://bzed.de/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
brian m. carlson
2007-11-11 18:57:32 UTC
Permalink
[lpr is standard on Unix]
Post by Bernd Zeimetz
That works well with cups if you have the cupsys-bsd package installed.
More importantly, programs (gv comes to mind) that don't have native
printing support but use an external program almost always use lpr, not
lp. (I can think of at most one that used lp, and numerous ones that
used lpr.) So if we use CUPS as the default printing package, we almost
certainly need the BSD utilities installed as well.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Steve Langasek
2007-11-12 20:08:25 UTC
Permalink
Post by Manoj Srivastava
Post by Russ Allbery
Also, do we really need *any* printing system as priority: standard?
It's not clear to me that printing is still really part of a standard
Unix installation, even for desktop users (and it definitely isn't for
servers).
Way back when, “standard” was defined as stuff that an old UNIX
hand would say “WTF happened to that?” if it is not present on a
default install. While I am unsure of this definition of standard still
holds,
According to Policy, this is the definition of "important" rather than
"standard"? ("Standard" is defined as "what we install by default", where
the core UNIX stuff is identified as the "important" subset of this.)
Post by Manoj Srivastava
but as an old UNIX hand I can say that if I am on a UNIX like
machine, and I can't just say lpr foo.txt and have it printed on the
default printer, I would find the system deficient and un-UNIX like.
How the printing occurs is not significant, as long as it can.
To satisfy this I guess we would need to raise the priority of both cupsys
and cupsys-bsd.

I'm assuming that re-raising the priority of lpr is not a reasonable means
of addressing this, since that's now a completely separate printing
implementation than the one used by default on the desktop now and AFAICS it
doesn't make sense to use two different defaults for these purposes.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
***@debian.org http://www.debian.org/
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Josselin Mouette
2007-11-13 09:33:30 UTC
Permalink
Post by Steve Langasek
I'm assuming that re-raising the priority of lpr is not a reasonable means
of addressing this, since that's now a completely separate printing
implementation than the one used by default on the desktop now and AFAICS it
^^^^^^^^^^
Post by Steve Langasek
doesn't make sense to use two different defaults for these purposes.
I should add that it's not only a default anymore. Since GTK+ 2.12
(maybe 2.10 ?) printers made available through lpr aren't even displayed
in the print dialog box, and you need to change your gtkrc if you want
to see them.
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
Marc 'HE' Brockschmidt
2007-11-11 18:12:35 UTC
Permalink
Post by Russ Allbery
Also, do we really need *any* printing system as priority: standard? It's
not clear to me that printing is still really part of a standard Unix
installation, even for desktop users (and it definitely isn't for
servers).
I believe it to be one of the more important bits of a standard Unix
*desktop* installation - but this just reminds me of the fact that I'm
quite uncomfortable with keeping a system like package priorities around
for much longer. Diverging use-cases (like in this case) show that one
definition of "standard" isn't really helpful anymore.

I think we may want to start thinking about getting rid of the whole
thing and switching to something which allows us to express more complex
importance measurements for packages. In fact, d-i and its task system
have been a step in that direction, so we maybe should evaluate if we
want to formalize it a bit more and get it into policy to replace
priorities.

Marc
--
BOFH #4:
static from nylon underwear
Leo "costela" Antunes
2007-11-11 21:15:08 UTC
Permalink
[not subscribed to -policy, just keeping original cross-posting]
Post by Marc 'HE' Brockschmidt
I think we may want to start thinking about getting rid of the whole
thing and switching to something which allows us to express more complex
importance measurements for packages. In fact, d-i and its task system
have been a step in that direction, so we maybe should evaluate if we
want to formalize it a bit more and get it into policy to replace
priorities.
Seconded.
A use-case based priority system is clearly - IMHO - a better suited
system then the "Priority:" paradigm for a distribution as broad
reaching as Debian.
Whether by extending the tasks system, the Priority paradigm (by perhaps
including a [use-case] tag, for instance: "Priority: standard
[!embeded]") or another wholly different approach, this seems like a
worthwhile idea.

One of the possible advantages for a different paradigm would be for
"reduced" CDDs, such as Emdebian, whose standard set of packages might
divert considerably by having _less_ packages, in which case the current
task system would fall short, AFAICT.

Cheers
--
Leo "costela" Antunes
[insert a witty retort here]
Steve Langasek
2007-11-15 01:59:15 UTC
Permalink
Post by Marc 'HE' Brockschmidt
Post by Russ Allbery
Also, do we really need *any* printing system as priority: standard? It's
not clear to me that printing is still really part of a standard Unix
installation, even for desktop users (and it definitely isn't for
servers).
I believe it to be one of the more important bits of a standard Unix
*desktop* installation - but this just reminds me of the fact that I'm
quite uncomfortable with keeping a system like package priorities around
for much longer. Diverging use-cases (like in this case) show that one
definition of "standard" isn't really helpful anymore.
Well, sure it is; it defines the lowest common denominator that we think
should be installed by default on all systems. Just because it may be
difficult to decide what that is doesn't make "standard" irrelevant, because
we still /do/ have to decide what we're going to install by default. :)
Post by Marc 'HE' Brockschmidt
I think we may want to start thinking about getting rid of the whole
thing and switching to something which allows us to express more complex
importance measurements for packages. In fact, d-i and its task system
have been a step in that direction, so we maybe should evaluate if we
want to formalize it a bit more and get it into policy to replace
priorities.
The d-i task system looks at the Priority: standard packages to assemble the
"standard" task...
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
***@debian.org http://www.debian.org/
Marc 'HE' Brockschmidt
2007-11-15 11:19:33 UTC
Permalink
Post by Steve Langasek
Post by Marc 'HE' Brockschmidt
Post by Russ Allbery
Also, do we really need *any* printing system as priority: standard? It's
not clear to me that printing is still really part of a standard Unix
installation, even for desktop users (and it definitely isn't for
servers).
I believe it to be one of the more important bits of a standard Unix
*desktop* installation - but this just reminds me of the fact that I'm
quite uncomfortable with keeping a system like package priorities around
for much longer. Diverging use-cases (like in this case) show that one
definition of "standard" isn't really helpful anymore.
Well, sure it is; it defines the lowest common denominator that we think
should be installed by default on all systems. Just because it may be
difficult to decide what that is doesn't make "standard" irrelevant, because
we still /do/ have to decide what we're going to install by default. :)
Yes, but our current framework makes the decision more complex than it
needs to be: What we kick out from standard is either in the (gigantic)
desktop task or not installed at all anymore. Having a
standard-{desktop,server,...} task would make it easier.
Post by Steve Langasek
Post by Marc 'HE' Brockschmidt
I think we may want to start thinking about getting rid of the whole
thing and switching to something which allows us to express more complex
importance measurements for packages. In fact, d-i and its task system
have been a step in that direction, so we maybe should evaluate if we
want to formalize it a bit more and get it into policy to replace
priorities.
The d-i task system looks at the Priority: standard packages to assemble the
"standard" task...
Sure, but it also provides tasks that split up optional and extra into
manageable chunks. The need for that is not disputed, simply because of
the number of packages that are << standard. I just believe that the
number of candidates for standard has increased enough to make it
reasonable to apply a similar split.

Most people have no idea what the actual difference between extra and
optional is supposed to be, in fact, most people only work with two
priorities: standard and !standard.

Marc
--
Fachbegriffe der Informatik - Einfach erklärt
98: Emacs
emacs makes any computer slow
Anthony Towns
2007-12-06 14:01:43 UTC
Permalink
Post by Marc 'HE' Brockschmidt
I believe it to be one of the more important bits of a standard Unix
*desktop* installation - but this just reminds me of the fact that I'm
quite uncomfortable with keeping a system like package priorities around
for much longer. Diverging use-cases (like in this case) show that one
definition of "standard" isn't really helpful anymore.
Haven't we more or less already moved away from priorities as meaning
anything particularly important? We have:

required/essential -- stuff that can't be removed: libc, dpkg, etc
important -- the rest of base, stuff necessary to bootstrap and
recover a usable and useful system
standard -- a minimal collection of useful stuff we'd like to see on
every Debian system
optional -- all the good software in the world
extra -- obscure stuff

All the really important questions are which bits of "optional" (and
occassionally extra) are useful for a given user.

I'm not sure if there's any point to continuing to try to make sure that
nothing >= optional conflicts with anything else >= optional.
Post by Marc 'HE' Brockschmidt
I think we may want to start thinking about getting rid of the whole
thing and switching to something which allows us to express more complex
importance measurements for packages. In fact, d-i and its task system
have been a step in that direction, so we maybe should evaluate if we
want to formalize it a bit more and get it into policy to replace
priorities.
required and important are both needed by debootstrap, so can't be gotten
rid of (though they could be changed to use some other field/name).

Priority: standard currently contains:

at, bc, dc, lsof, file, less, sharutils, strace
dnsutils, ftp, host, ssh, mtr-tiny, finger, w3m, whois
doc-debian, doc-linux-text
exim, mailx, mutt, procmail, mime-support, mpack
gettext-base, locales
pciutils
perl (not just perl-base), python
reportbug
selinux policy

That seems a pretty reasonable set of functionality to put on all Debian
boxes (unless the admin specifically says otherwise), afaics.

It might be sensible to replace ftp with lftp these days, though. And
I'm not sure what happened to the exim v postfix defaults discussion a
little while ago, and maybe procmail/mpack aren't all that necessary.

It also includes, but afaics, probably doesn't need to (anymore):

ispell, dictionaries-common, iamerican, ibritish, wamerican
m4, texinfo (???)
mtools (access unmounted msdos filesystems, not NTFS though)
nfs-common, portmap (enables mounting NFS shares)
pidentd (is IDENT still used on today's internet, with all its NAT?)
openbsd-inetd (needed by pidentd)
tcsh (people who remember what it is know how to install it)
time (???)
telnet (netcat is important, as is wget)

But as far as "default installs" for anything of any real meaning,
I just don't see Priorities as being relevant anymore.

Cheers,
aj
Russ Allbery
2007-12-06 15:42:06 UTC
Permalink
Post by Anthony Towns
ispell, dictionaries-common, iamerican, ibritish, wamerican
m4, texinfo (???)
texinfo possibly for info and dating from the days of needing to have an
info reader to get real documentation for many of the GNU tools?
Post by Anthony Towns
mtools (access unmounted msdos filesystems, not NTFS though)
Probably obsolete at this point.
Post by Anthony Towns
nfs-common, portmap (enables mounting NFS shares)
pidentd (is IDENT still used on today's internet, with all its NAT?)
openbsd-inetd (needed by pidentd)
identd is still used somewhat, mostly with IRC, but it's almost certainly
optional rather than standard.
Post by Anthony Towns
tcsh (people who remember what it is know how to install it)
Having a /bin/csh falls into "present on all Unix systems and likely to
provoke WTF reactions if not there." Also, I'm pretty sure that tcsh is
very comfortably the second-most-used interactive shell, way ahead of
zsh, on Linux systems.

Lots of us old-timers haven't made the leap for our interactive shell
yet. :) And it's probably more common among the average user than among
DDs, since DDs are more likely to be interested in playing with the latest
and greatest stuff.
Post by Anthony Towns
time (???)
Likewise. time is a standard Unix program.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Anthony Towns
2007-12-06 18:51:29 UTC
Permalink
Post by Russ Allbery
Post by Anthony Towns
ispell, dictionaries-common, iamerican, ibritish, wamerican
m4, texinfo (???)
texinfo possibly for info and dating from the days of needing to have an
info reader to get real documentation for many of the GNU tools?
But texinfo only includes:
/usr/bin/texi2pdf
/usr/bin/texindex
/usr/bin/texi2dvi
/usr/bin/ginstall-info
/usr/bin/makeinfo

The info browser is in the info package (which is priority:important)...
Post by Russ Allbery
Post by Anthony Towns
mtools (access unmounted msdos filesystems, not NTFS though)
Probably obsolete at this point.
Post by Anthony Towns
pidentd (is IDENT still used on today's internet, with all its NAT?)
openbsd-inetd (needed by pidentd)
identd is still used somewhat, mostly with IRC, but it's almost certainly
optional rather than standard.
Post by Anthony Towns
tcsh (people who remember what it is know how to install it)
Having a /bin/csh falls into "present on all Unix systems and likely to
provoke WTF reactions if not there."
Which isn't a requirement for "standard", but hey...
Post by Russ Allbery
Also, I'm pretty sure that tcsh is
very comfortably the second-most-used interactive shell, way ahead of
zsh, on Linux systems.
#rank name inst vote old recent no-files
2 bash 69802 58316 2596 8885 5
305 mailx 62713 16369 30995 15343 6
438 tcsh 60057 9042 37123 13886 6
488 mutt 59151 7662 32588 18895 6
555 mtools 60985 6035 40222 14723 5
570 reportbug 61436 5780 40836 14816 4
588 time 61236 5539 41423 14267 7
885 dash 11100 2615 7604 876 5
1014 zsh 3801 2002 1366 431 2

Of course, there's half a zillion different zsh packages that should have
their stats combined, but whatever.

I find it pretty surprising that somewhere between 1 in 8 systems
(vote/max(inst)) and 1 in 5 systems ((vote+old)/vote) still have tcsh
used recently tbh.
Post by Russ Allbery
Post by Anthony Towns
time (???)
Likewise. time is a standard Unix program.
And which is a built-in on bash, tcsh and zsh, so doesn't seem terribly
useful most of the time... (not dash though)

Cheers,
aj
Russ Allbery
2007-12-06 19:31:40 UTC
Permalink
Post by Anthony Towns
Post by Russ Allbery
Post by Anthony Towns
tcsh (people who remember what it is know how to install it)
Having a /bin/csh falls into "present on all Unix systems and likely to
provoke WTF reactions if not there."
Which isn't a requirement for "standard", but hey...
Yeah, it's the definition of important, and I could make an argument that
having /bin/csh in important would be justified. But on the other hand,
it's bad for scripting and probably should generally be discouraged, so.
Standard seems like a reasonable compromise. :)
Post by Anthony Towns
I find it pretty surprising that somewhere between 1 in 8 systems
(vote/max(inst)) and 1 in 5 systems ((vote+old)/vote) still have tcsh
used recently tbh.
Up until fairly recently, it was the only interactive shell with decent
programmable completion other than zsh. (bash's has been substandard
compared to tcsh for many years, although I think in recent years it's
gotten a lot closer.) And zsh is a little intimidating to get started
with.

I still use tcsh as an interactive shell in large part because I can't
figure out how to duplicate certain behaviors that my fingers are very
used to in bash, although it's probably possible at this point. bash used
to have a hard time with stuff like:

complete pubswtrawl 'n%--recheck%D:/afs/.ir/pubsw/ADMIN/links/%'
complete cvs 'p/1/(add commit diff log remove status update)/'
Post by Anthony Towns
Post by Russ Allbery
Post by Anthony Towns
time (???)
Likewise. time is a standard Unix program.
And which is a built-in on bash, tcsh and zsh, so doesn't seem terribly
useful most of the time... (not dash though)
True.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
brian m. carlson
2007-12-06 20:58:33 UTC
Permalink
Post by Anthony Towns
Post by Russ Allbery
Post by Anthony Towns
time (???)
Likewise. time is a standard Unix program.
And which is a built-in on bash, tcsh and zsh, so doesn't seem terribly
useful most of the time... (not dash though)
I've never seen anyone use either dash or posh as their default shell,
and IME time is only used in interactive shells, so this might not be
that important. IMHO it could be relegated to optional.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Ben Pfaff
2007-12-06 21:34:10 UTC
Permalink
Post by brian m. carlson
Post by Anthony Towns
Post by Russ Allbery
Post by Anthony Towns
time (???)
Likewise. time is a standard Unix program.
And which is a built-in on bash, tcsh and zsh, so doesn't seem terribly
useful most of the time... (not dash though)
I've never seen anyone use either dash or posh as their default shell,
and IME time is only used in interactive shells, so this might not be
that important. IMHO it could be relegated to optional.
I use "time" in benchmarking scripts.
--
Ben Pfaff
http://benpfaff.org
Manoj Srivastava
2007-12-06 23:09:36 UTC
Permalink
Post by Ben Pfaff
I use "time" in benchmarking scripts.
I do not find the built in time to be a substitute for the good
old fashioned time command. Observe:

__> time sleep 20
Real: 20.03s User: 0.00s System: 0.00s Percent: 0% Cmd: sleep 20
__> /usr/bin/time sleep 20
0.00user 0.00system 0:20.01elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+188minor)pagefaults 0swaps
__> time -v sleep 2
zsh: command not found: -v
[3] 4136 exit 127 -v sleep 2
Real: 0.00s User: 0.00s System: 0.00s Percent: 0% Cmd: -v sleep 2
__> /usr/bin/time -v sleep 2
Command being timed: "sleep 2"
User time (seconds): 0.00
System time (seconds): 0.00
Percent of CPU this job got: 0%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:02.00
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 0
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 192
Voluntary context switches: 3
Involuntary context switches: 0
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0

manoj
--
Men never make passes at girls wearing glasses. Dorothy Parker
Manoj Srivastava <***@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Ben Pfaff
2007-12-06 23:45:33 UTC
Permalink
Post by Manoj Srivastava
Post by Ben Pfaff
I use "time" in benchmarking scripts.
I do not find the built in time to be a substitute for the good
old fashioned time command. [...]
Which is one reason why I wrote the above, in support of keeping
"time" at Priority: standard. Perhaps I was not explicit enough.
--
Ben Pfaff
http://benpfaff.org
Anthony Towns
2007-12-07 02:28:55 UTC
Permalink
Post by Manoj Srivastava
Post by Ben Pfaff
I use "time" in benchmarking scripts.
I do not find the built in time to be a substitute for the good
Why are either of those reasons to have /usr/bin/time on every Debian
machine? We're not talking about removing the package entirely...

(For comparison: nc/telnet are basic diagnostic tools to investigate why
you can't run apt-get, reportbug, an email program and a web browser are
needed for contacting remote humans if you get into problems installing
or recovering a Debian system)

Cheers,
aj
Ben Pfaff
2007-12-07 05:02:24 UTC
Permalink
Post by Anthony Towns
Post by Manoj Srivastava
Post by Ben Pfaff
I use "time" in benchmarking scripts.
I do not find the built in time to be a substitute for the good
Why are either of those reasons to have /usr/bin/time on every Debian
machine? We're not talking about removing the package entirely...
It's hard for me to believe that a standard Unix utility should
not be in "standard" or perhaps even in "important". As policy
says about the "important" priority, "we are trying to produce,
amongst other things, a free Unix."

But, as with almost every other program, if it's not installed, I
can install it quickly and conveniently, so it's frankly not
worth much arguing either way from my point of view.
--
Ben Pfaff
http://benpfaff.org
Manoj Srivastava
2007-12-07 05:03:08 UTC
Permalink
Post by Anthony Towns
Post by Ben Pfaff
I use "time" in benchmarking scripts.
I do not find the built in time to be a substitute for the good old
Why are either of those reasons to have /usr/bin/time on every Debian
machine? We're not talking about removing the package entirely...
The passage you are quoting is not meant to offer justification
for keeping time in standard. It was meant to refure the statement that
time is now a builtin in most shells.

The point I am making is that the built in command of the same
name as /usr/bin/time is a pale shade of the original, and in no way an
adequate substitute.

Now, the justification is that it has always been a part of
UNIX, as far back I I can remember (Which means about '83 -- though I
honestly only recall the executable /usr/bin/time on Ultrix, circa
'88).

Frankly, I suggest we look at the list of Unix commands as
specified by the SUS -- which can also be seen at:
http://en.wikipedia.org/wiki/List_of_Unix_programs

From that page, time has been in UNIX since AT&T version 3.

So -- how many of the standard unix commands as defined by that
page are not part of the standard section?

manoj
--
The difference between genius and stupidity is that genius has its
limits.
Manoj Srivastava <***@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Anthony Towns
2007-12-07 08:06:12 UTC
Permalink
Post by Manoj Srivastava
Frankly, I suggest we look at the list of Unix commands as
http://en.wikipedia.org/wiki/List_of_Unix_programs
So -- how many of the standard unix commands as defined by that
page are not part of the standard section?
I guess one of the the things I wonder every now and then
is whether we really should be keeping standard as implying a
... traditional/historical/whatever Unix system, with pr and lpr and tcsh
and bc and dc and whatever else that people would traditionally expect,
instead of moving them to a task that can be installed only by people
who actually know what they are, and then making sure we provide a real
Unix system in that case. But by the looks of things there's still not
much need for a change there, at least at this point.

Cheers,
aj
Bernd Zeimetz
2007-12-06 22:11:40 UTC
Permalink
Post by Russ Allbery
Having a /bin/csh falls into "present on all Unix systems and likely to
provoke WTF reactions if not there." Also, I'm pretty sure that tcsh is
very comfortably the second-most-used interactive shell, way ahead of
zsh, on Linux systems.
Although csh is the standard on a lot of systems, including OSX, it is
'bashed' for being bad in Debian's policy. But I wanted to send a bug
about that anyway...
--
Bernd Zeimetz
<***@bzed.de> <http://bzed.de/>
Russ Allbery
2007-12-06 22:23:28 UTC
Permalink
Post by Bernd Zeimetz
Post by Russ Allbery
Having a /bin/csh falls into "present on all Unix systems and likely to
provoke WTF reactions if not there." Also, I'm pretty sure that tcsh
is very comfortably the second-most-used interactive shell, way ahead
of zsh, on Linux systems.
Although csh is the standard on a lot of systems, including OSX, it is
'bashed' for being bad in Debian's policy. But I wanted to send a bug
about that anyway...
It should be bashed for scripting. It's a horrible scripting shell with a
bunch of problems, starting with but not limited to its I/O redirection
support.

Interactive shells have different needs, though, and Policy doesn't say
anything about using csh as an interactive shell that I'd seen (if I'm
wrong, please do point it out).
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Yves-Alexis Perez
2007-12-07 07:21:18 UTC
Permalink
Post by Bernd Zeimetz
Although csh is the standard on a lot of systems, including OSX
OSX uses bash by default since Panther (10.3).
--
Yves-Alexis
Manoj Srivastava
2007-12-06 16:26:11 UTC
Permalink
Post by Anthony Towns
Haven't we more or less already moved away from priorities as meaning
* required/essential -- stuff that can't be removed: libc, dpkg,etc
Packages which are required to be present for the packaging
system to be able to install additional packages. This means dpkg and
everything dpkg itself needs; if these packages are gone, the system
can't repair itself, and can not move to a more tenable state.
Post by Anthony Towns
* important -- the rest of base, stuff necessary to bootstrap
and recover a usable and useful system
The subset of the OS required to boot and be able to install
further packages. Note that just required packages might not constitue
a bootable system.
Post by Anthony Towns
* standard -- a minimal collection of useful stuff we'd like to
see on every Debian system
optional -- all the good software in the world
extra -- obscure stuff
If we are removing the invariant that everything in optional
should not conflict with anything else in optional, and extra is where
the conflicing packages go, is there any reason to retain extra as a
distinct section?
Post by Anthony Towns
I'm not sure if there's any point to continuing to try to make sure
that nothing >= optional conflicts with anything else >= optional.
Hmm. Can you elaborate on this, please? Is it because it is too
hard to achieve this? Or you think this is something unattainable even
in theory? It is a nice invariant, if only we could get it to hold for
Debian.

manoj
--
Hacking's just another word for nothing left to kludge.
Manoj Srivastava <***@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Neil Williams
2007-12-06 18:55:12 UTC
Permalink
Post by Manoj Srivastava
Post by Anthony Towns
Haven't we more or less already moved away from priorities as meaning
optional -- all the good software in the world
extra -- obscure stuff
If we are removing the invariant that everything in optional
should not conflict with anything else in optional, and extra is where
the conflicing packages go, is there any reason to retain extra as a
distinct section?
I'd like 'extra' to disappear - so if there is a move to do that, I'm
all for it.
Post by Manoj Srivastava
Post by Anthony Towns
I'm not sure if there's any point to continuing to try to make sure
that nothing >= optional conflicts with anything else >= optional.
Hmm. Can you elaborate on this, please? Is it because it is too
hard to achieve this? Or you think this is something unattainable even
in theory? It is a nice invariant, if only we could get it to hold for
Debian.
I have uploaded gpe-conf which is a configuration GUI for GPE (embedded)
and it doesn't sit well with larger, more complex, control centre apps
like kcontrol or gnome-control-center. It's not that surprising, GPE is
meant to be a replacement for Gnome on embedded devices that do not have
the space for Gnome. So I added a Conflict against gnome-control-center
and kcontrol - it doesn't stop people using the GPE applications in
other environments but it does prevent the simpler approach of gpe-conf
causing trouble with the more complex needs of gnome-control-center and
kcontrol. There's no point extending gpe-conf to be a mimic of
gnome-control-center (it's already one of the largest GPE packages) and
there's little point getting gpe-conf to play nicely with
gnome-control-center because the two are aimed at very different
users/devices.

I don't see why it is wrong for these optional packages to conflict.

(There's a separate issue that the gpe meta-package currently depends on
gsoko that is extra but that's minor - I can drop the gsoko depends on
the meta package without too much of a problem.)
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
brian m. carlson
2007-12-06 21:17:28 UTC
Permalink
Post by Neil Williams
I'd like 'extra' to disappear - so if there is a move to do that, I'm
all for it.
I disagree with this. I think that this distinction is useful, and I
have in the past filed bugs because of it. Granted, IANADD, but I do
the occasional bit of bug work.

[gpe-conf, an embedded control center, conflicts with part of kde/gnome]
Post by Neil Williams
I don't see why it is wrong for these optional packages to conflict.
I think gpe-conf should be extra. Most Debian installations are either
desktops or servers. This is obvious from popcon results, where the top
three architectures are i386, amd64, and powerpc (followed closely by
arm). If people are running a server, they don't want any graphical
environment installed, and if people are running a desktop, they don't
want GPE installed.

I'm not saying that embedded applications aren't important, lest you get
that idea. I'm saying that the majority of installations do not want or
need gpe-conf, so it should be extra. It's a tool for certain special
environments. Note that this differs from tools like sparc-utils, that
although they are specific to an architecture, are very useful on those
machines, and so might legitimately be priority optional or even
standard.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Neil Williams
2007-12-06 21:36:58 UTC
Permalink
Post by brian m. carlson
Post by Neil Williams
I'd like 'extra' to disappear - so if there is a move to do that, I'm
all for it.
I disagree with this. I think that this distinction is useful, and I
have in the past filed bugs because of it. Granted, IANADD, but I do
the occasional bit of bug work.
There is no functional or useful distinction between optional and extra,
as far as I can see - what are you trying to retain?

My principle query is why "optional" is not supposed to support Conflicts.
Post by brian m. carlson
[gpe-conf, an embedded control center, conflicts with part of kde/gnome]
Post by Neil Williams
I don't see why it is wrong for these optional packages to conflict.
I think gpe-conf should be extra.
1. That doesn't solve the conflict because gnome-control-center and
kcontrol are still optional
2. It would require migrating some 40 packages from optional to extra
for - as far as I can tell - no good reason. Simpler just to ditch the
Conflicts rule for optional and drop extra completely.

Alternatively, replace 'extra' with 'arch-specific' where packages like
sparc-utils can have a higher priority on sparc and be ignored elsewhere.
Post by brian m. carlson
Most Debian installations are either
desktops or servers. This is obvious from popcon results, where the top
three architectures are i386, amd64, and powerpc (followed closely by
arm). If people are running a server, they don't want any graphical
environment installed, and if people are running a desktop, they don't
want GPE installed.
Not true. GPE offers a desktop - just not a full Gnome desktop. There
are plenty of alternative desktops in optional already. The full GPE
environment is quite specialised but Debian does claim to the The
Universal OS. Emdebian is concentrating on arm but any architecture can
run GPE.
Post by brian m. carlson
I'm not saying that embedded applications aren't important, lest you get
that idea.
GPE is in Debian and is intended for any low resource implementation. It
is being cross built for Emdebian as it is particularly suitable for
embedded devices but there is no particular reason why GPE could not be
used on other low resource Debian installations - with the exception
that it does tend to expect quite small screen sizes and some of the
windows are quite difficult to use at high res.

I've got a few more packages to add to flesh it out too.
Post by brian m. carlson
I'm saying that the majority of installations do not want or
need gpe-conf, so it should be extra.
I don't follow the logic - nor do I see why that is different to the
other desktop options that are not KDE or Gnome which are also intended
for special or low resource environments.

I see no reason for any distinction between what is currently optional
and what is currently 'extra'.
Post by brian m. carlson
It's a tool for certain special
environments. Note that this differs from tools like sparc-utils, that
although they are specific to an architecture,
That's a red herring, IMHO, because GPE is not specific to an architecture.
Post by brian m. carlson
are very useful on those
machines, and so might legitimately be priority optional or even standard.
That seems to argue for a architecture-specific priority - a meta
prority where is $arch eq "sparc" priority = required else priority = extra.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Russ Allbery
2007-12-06 21:45:07 UTC
Permalink
Post by Neil Williams
There is no functional or useful distinction between optional and extra,
as far as I can see - what are you trying to retain?
One distinction we have at the moment that I personally think is useful is
that things that most users don't care about unless they're specifically
looking for them (development packages, detached debugging symbols, that
sort of thing) are priority: extra. At least in dselect that meant they
weren't shown to the user in the same category as everything else. I
don't use anything but aptitude on the command-line these days, so I'm not
sure if the display differs in more modern interfaces, but it's useful at
least in theory to hide classes of things that the user doesn't much care
about.

On the other hand, suppressing the libdevel category would probably
accomplish much the same.
Post by Neil Williams
Not true. GPE offers a desktop - just not a full Gnome desktop. There
are plenty of alternative desktops in optional already. The full GPE
environment is quite specialised but Debian does claim to the The
Universal OS. Emdebian is concentrating on arm but any architecture can
run GPE.
Any time that you say something is "quite specialized," to me that means
it should be priority: extra. (Although you may not be referring to the
whole thing.)

A bunch of my packages are priority: extra because they're only of use to
some Kerberos sites. It's not a mark of shame. :)
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Neil Williams
2007-12-06 22:12:57 UTC
Permalink
Post by Russ Allbery
Post by Neil Williams
Not true. GPE offers a desktop - just not a full Gnome desktop. There
are plenty of alternative desktops in optional already. The full GPE
environment is quite specialised but Debian does claim to the The
Universal OS. Emdebian is concentrating on arm but any architecture can
run GPE.
Any time that you say something is "quite specialized," to me that means
it should be priority: extra. (Although you may not be referring to the
whole thing.)
Correct - GPE contains many applications that are useful in a variety of
desktop environments. The full GPE environment (such as would be
installed using the 'gpe' meta-package provided by gpe-conf) aims to
replace Gnome or KDE within the more limited needs of a specialised
environment. So GPE components can be used anywhere, the full GPE
environment, including gpe-conf and gpe-login, is different.

Whilst most GPE components can be used separately, the full environment
needs to replace the existing desktop whether that be Gnome or KDE or
chaos may ensue due to the different needs of the target environments
and the underlying configuration mechanisms and solutions.

I would have put gpe-conf into extra but it needs to depend on packages
that are in optional because those can be used within Gnome or KDE or
any other desktop. This is where the division between optional and extra
seems entirely arbitrary to me. If the reasons are historical, I would
like to propose that 'extra' is dropped or renamed as
'architecture-specific' or something of that kind.
Post by Russ Allbery
A bunch of my packages are priority: extra because they're only of use to
some Kerberos sites. It's not a mark of shame. :)
I understand that - and I agree with you. However, packages in extra are
not supposed to depend upon or conflict with packages in optional and to
me, that makes no sense and just makes things difficult - especially
when combined with the line about not having conflicts within optional
itself.

What is the reason for having no conflicts between optional packages? Is
it still relevant? What is meant to happen when a package in extra *has
to* conflict with a package in optional?
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Russ Allbery
2007-12-06 22:33:17 UTC
Permalink
Post by Neil Williams
I would have put gpe-conf into extra but it needs to depend on packages
that are in optional because those can be used within Gnome or KDE or
any other desktop.
I'm missing why this is a problem. Priority: extra packages can depend on
Priority: optional packages. What's not allowed is the other way around.
Post by Neil Williams
I understand that - and I agree with you. However, packages in extra are
not supposed to depend upon or conflict with packages in optional
Hm, this seems exactly backwards to me. It's packages with Priority:
extra that *are* allowed to conflict with packages that are Priority:
optional.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Steve Langasek
2007-12-06 22:33:53 UTC
Permalink
Post by Neil Williams
Whilst most GPE components can be used separately, the full environment
needs to replace the existing desktop whether that be Gnome or KDE or
chaos may ensue due to the different needs of the target environments
and the underlying configuration mechanisms and solutions.
How does that warrant a conflict then? It's entirely possible to have both
GNOME and KDE installed on a system and choose between them at runtime.
Post by Neil Williams
I would have put gpe-conf into extra but it needs to depend on packages
that are in optional because those can be used within Gnome or KDE or
any other desktop.
Lots of packages depend on other packages of higher priority, that's
perfectly normal.
Post by Neil Williams
I understand that - and I agree with you. However, packages in extra are
not supposed to depend upon or conflict with packages in optional and to
me, that makes no sense and just makes things difficult
No, it doesn't make any sense, and it's not correct in the least. Where did
you get this?

Packages in *optional* are not supposed to conflict with other packages of
priority *optional*. Packages are not supposed to depend on packages with a
*lower* priority. It's certainly ok for packages in extra to depend on
packages in optional, and *conflicting* with packages in optional is one of
the stated criteria for putting packages /into/ extra.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org
Neil Williams
2007-12-06 22:48:12 UTC
Permalink
Steve Langasek wrote:

Bah, got the reply address wrong too - should have left this until the
morning . . .
Post by Steve Langasek
Post by Neil Williams
Whilst most GPE components can be used separately, the full environment
needs to replace the existing desktop whether that be Gnome or KDE or
chaos may ensue due to the different needs of the target environments
and the underlying configuration mechanisms and solutions.
How does that warrant a conflict then? It's entirely possible to have both
GNOME and KDE installed on a system and choose between them at runtime.
From earlier in this thread:

I have uploaded gpe-conf which is a configuration GUI for GPE (embedded)
and it doesn't sit well with larger, more complex, control centre apps
like kcontrol or gnome-control-center. It's not that surprising, GPE is
meant to be a replacement for Gnome on embedded devices that do not have
the space for Gnome. So I added a Conflict against gnome-control-center
and kcontrol - it doesn't stop people using the GPE applications in
other environments but it does prevent the simpler approach of gpe-conf
causing trouble with the more complex needs of gnome-control-center and
kcontrol. There's no point extending gpe-conf to be a mimic of
gnome-control-center (it's already one of the largest GPE packages) and
there's little point getting gpe-conf to play nicely with
gnome-control-center because the two are aimed at very different
users/devices.

and

Whilst most GPE components can be used separately, the full environment
needs to replace the existing desktop whether that be Gnome or KDE or
chaos may ensue due to the different needs of the target environments
and the underlying configuration mechanisms and solutions.
Post by Steve Langasek
Post by Neil Williams
I would have put gpe-conf into extra but it needs to depend on packages
that are in optional because those can be used within Gnome or KDE or
any other desktop.
Lots of packages depend on other packages of higher priority, that's
perfectly normal.
Mea culpa. Got it mixed up.

Should have stuck with my first decision and put gpe-conf in extra where
it can conflict with stuff in optional.
:-(
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Steve Langasek
2007-12-06 23:04:40 UTC
Permalink
Post by Neil Williams
Post by Steve Langasek
Post by Neil Williams
Whilst most GPE components can be used separately, the full environment
needs to replace the existing desktop whether that be Gnome or KDE or
chaos may ensue due to the different needs of the target environments
and the underlying configuration mechanisms and solutions.
How does that warrant a conflict then? It's entirely possible to have both
GNOME and KDE installed on a system and choose between them at runtime.
I have uploaded gpe-conf which is a configuration GUI for GPE (embedded)
and it doesn't sit well with larger, more complex, control centre apps
like kcontrol or gnome-control-center. It's not that surprising, GPE is
meant to be a replacement for Gnome on embedded devices that do not have
the space for Gnome. So I added a Conflict against gnome-control-center
and kcontrol - it doesn't stop people using the GPE applications in
other environments but it does prevent the simpler approach of gpe-conf
causing trouble with the more complex needs of gnome-control-center and
kcontrol.
Ok, that rationale doesn't make any sense to me. While there's nothing in
policy that prohibits conflicting with arbitrary packages, the main reason
why conflicts are added is because the packages conflict at the /filesystem/
level. The second most common reason for adding conflicts seems to be
because two packages want to provide the same network service on the same
port, and even that usage has been debated.

Causing packages to conflict merely because they provide overlapping
functionality is not at all the norm, and I don't really think that's a good
idea.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org
brian m. carlson
2007-12-06 23:16:39 UTC
Permalink
Post by Neil Williams
There is no functional or useful distinction between optional and extra,
as far as I can see - what are you trying to retain?
If the distinction that is outlined in policy is followed, it is useful.
It guarantees that all of optional is installable. It also guarantees
that a useful system can be installed from packages that are priority
optional or higher.
Post by Neil Williams
My principle query is why "optional" is not supposed to support Conflicts.
For the very reason that all of optional is supposed to be installable.
Post by Neil Williams
Post by brian m. carlson
I think gpe-conf should be extra.
1. That doesn't solve the conflict because gnome-control-center and
kcontrol are still optional
Right. But then the conflicting package is extra, and
gnome-control-center and kcontrol don't conflict with each other
(they both used to be installed on my desktop). The only package here
that conflicts is gpe-conf.

Packages which are extra can conflict with any package they want to, and
packages which are optional or higher can conflict with packages which
are extra. mail-transport-agent is a good example of the latter.
Post by Neil Williams
2. It would require migrating some 40 packages from optional to extra
for - as far as I can tell - no good reason. Simpler just to ditch the
Conflicts rule for optional and drop extra completely.
Those packages should always have been in extra from the start. The
fact that a large number of packages are buggy does not necessitate a
policy change. I have been using Debian since potato, and AFAICR, it
has always been this way. This is nothing new.
Post by Neil Williams
Not true. GPE offers a desktop - just not a full Gnome desktop. There
are plenty of alternative desktops in optional already. The full GPE
environment is quite specialised but Debian does claim to the The
Universal OS. Emdebian is concentrating on arm but any architecture can
run GPE.
It could very well be used in that way. The way you described it
implied that it was only suitable for embedded devices, which it
apparently isn't. I apologize for my misunderstanding.

The difference is that the alternative desktops don't all conflict with
one another. It is perfectly possible to have GNOME and KDE installed
together, and I guess you could have those co-installed with GNUStep,
XFCE4, and several other window managers as well. gpe-conf declares a
conflicts because it doesn't work with other systems well; you said so
yourself. Thus, gpe-conf is less important because it is less
bulletproof; it is a poorer choice overall. Hence, it should either
work better with other programs, or it should be in extra.
Post by Neil Williams
Post by brian m. carlson
I'm saying that the majority of installations do not want or
need gpe-conf, so it should be extra.
I don't follow the logic - nor do I see why that is different to the
other desktop options that are not KDE or Gnome which are also intended
for special or low resource environments.
The other environments don't conflict; gpe-conf (and the packages that
depend on it) does. That's the difference. If GPE did not conflict
with optional packages, it should be in optional. That's it.
Post by Neil Williams
I see no reason for any distinction between what is currently optional
and what is currently 'extra'.
The rationale has always been that all of optional should be
installable. That might not be something that many people want to do,
but we should still support it, because that way we guarantee that any
given subset of optional is also installable.
Post by Neil Williams
Post by brian m. carlson
It's a tool for certain special
environments. Note that this differs from tools like sparc-utils, that
although they are specific to an architecture,
That's a red herring, IMHO, because GPE is not specific to an architecture.
My point was that they are two different situations. Arch-specific
packages might legitimately be of standard or even important priority on
that architecture, but that's a distinction we can make, because they're
only built on that architecture. To give another example, silo is
priority important, because for sparc it is *the* bootloader. On amd64,
it has very little utility, which is okay, because it isn't built
there.
Post by Neil Williams
Post by brian m. carlson
are very useful on those
machines, and so might legitimately be priority optional or even standard.
That seems to argue for a architecture-specific priority - a meta
prority where is $arch eq "sparc" priority = required else priority = extra.
silo is useless on non-sparc archs, so it isn't built there. So, no, I
don't think we need an architecture-specific priority.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Anthony Towns
2007-12-06 18:26:46 UTC
Permalink
Post by Manoj Srivastava
Post by Anthony Towns
I'm not sure if there's any point to continuing to try to make sure
that nothing >= optional conflicts with anything else >= optional.
Hmm. Can you elaborate on this, please? Is it because it is too
hard to achieve this? Or you think this is something unattainable even
in theory? It is a nice invariant, if only we could get it to hold for
Debian.
I don't have any statistics to back the following up.

I don't think we have been doing it very thoroughly for years now, so
at best it's something that's often true, but not always (eg, there's
only one mail-transport-agent of priority optional or higher -- except
there's actually three: exim4-daemon-light (standard), exim4-daemon-heavy
and nbsmtp).

It requires us to choose a winner amongst similar packages that use
Conflicts instead of alternatives, when really we'd rather leave that
up to our users (or people maintaining derivative distros, or tasksel
or whatever).

I don't think it serves an actual point -- back in the day saying "install
everything of priority optional or above" was a feasible way of getting
a really powerful and useful Debian system. That's not really plausible
anymore thanks to the sheer amount of software.
Post by Manoj Srivastava
Post by Anthony Towns
optional -- all the good software in the world
extra -- obscure stuff
If we are removing the invariant that everything in optional
should not conflict with anything else in optional, and extra is where
the conflicing packages go, is there any reason to retain extra as a
distinct section?
Being able to classify software as "Unless you have a really special need,
you don't want this" still seems somewhat useful to me. I also somewhat
like the idea of having your average free software package in main at
a higher priority than your average non-free software package.

Cheers,
aj
NN_il_Confusionario
2007-12-07 07:25:05 UTC
Permalink
Post by Manoj Srivastava
Post by Anthony Towns
* required/essential -- stuff that can't be removed: libc, dpkg,etc
Packages which are required to be present for the packaging
system to be able to install additional packages. This means dpkg and
everything dpkg itself needs
Question: is there somewhere on the net a script (*) such that:

* it accepts two parameters: a debian release (etch, sarge, woody, ...)
and an (empty) directory;

* it installs required/essential packages (_all_ of them but _only_
them) of such a release as a chroot in that directory

? [Mybe also a third parameter will be useful, the architecture]

(*) complete and explicit lists to use with debootstrap are a solution.
(debootstrap by default installs quite more than really
required/essential packages).

Every time I do someting like that, too much time is spent for
dependency hunting. Ad every time I forget to save the list of packages :-(
--
Chi usa software non libero avvelena anche te. Digli di smettere.
Informatica=arsenico: minime dosi in rari casi patologici, altrimenti letale.
Informatica=bomba: intelligente solo per gli stupidi che ci credono.
Michal Čihař
2007-12-07 07:37:57 UTC
Permalink
Hi

On Fri, 7 Dec 2007 08:25:05 +0100
Post by NN_il_Confusionario
* it accepts two parameters: a debian release (etch, sarge, woody, ...)
and an (empty) directory;
* it installs required/essential packages (_all_ of them but _only_
them) of such a release as a chroot in that directory
? [Mybe also a third parameter will be useful, the architecture]
(*) complete and explicit lists to use with debootstrap are a solution.
(debootstrap by default installs quite more than really
required/essential packages).
Every time I do someting like that, too much time is spent for
dependency hunting. Ad every time I forget to save the list of packages :-(
Isn't minimal flavour in cdeboostrap doing this? So the script would
be: "cdebootstrap -f minimal sid /tmp/foobar".
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
NN_il_Confusionario
2007-12-07 09:20:50 UTC
Permalink
Post by Michal Čihař
On Fri, 7 Dec 2007 08:25:05 +0100
Post by NN_il_Confusionario
* it installs required/essential packages (_all_ of them but _only_
them) of such a release as a chroot in that directory
Isn't minimal flavour in cdeboostrap doing this?
the man page says:

minimal
Installs essential and apt.

so it should do _almost_ what I asked, but not exactly: at least apt and
its dependencies are added to dpkg and its dependencies.
--
Chi usa software non libero avvelena anche te. Digli di smettere.
Informatica=arsenico: minime dosi in rari casi patologici, altrimenti letale.
Informatica=bomba: intelligente solo per gli stupidi che ci credono.
Anthony Towns
2007-12-07 09:28:22 UTC
Permalink
Post by NN_il_Confusionario
* it installs required/essential packages (_all_ of them but _only_
them) of such a release as a chroot in that directory
You could create a variant for debootstrap. That's not very hard,
depending on your mood:

# cp /usr/share/debootstrap/scripts/sid my-sid
# patch <<EOF
@@ -9,7 +9,7 @@
mirror_style release
download_style apt
finddebs_style from-indices
-variants - buildd fakechroot
+variants - buildd fakechroot minbase

if doing_variant fakechroot; then
test "$FAKECHROOT" = "true" || error 1 FAKECHROOTREQ "This variant requires fakechroot environment to be started"
@@ -37,6 +37,8 @@
# ldd.fake needs binutils
required="$required binutils"
fi
+
+ if doing_variant minbase; then base="apt"; fi
}

first_stage_install () {
EOF
# debootstrap --variant=minbase sid target/ http://mirror.internode.on.net/pub/debian/

If you don't want apt and its dependencies, you can add "--include=ed
--exclude=apt" as arguments, or similar. If you don't have anything
at all in base, you'll get some ugly error messages, but I think it'll
still work.

OTOH, there's not much reason not to have that in debootstrap by default,
afaics. What the hey, patch committed. Look for it in version 1.0.8 when
it gets released.
Post by NN_il_Confusionario
Every time I do someting like that, too much time is spent for
dependency hunting. Ad every time I forget to save the list of packages :-(
debootstrap --print-debs will give you a list of packages. It includes
both required and base in the same list, so you have to look for the split
yourselve (zlibg1 and adduser atm), but that's not too hard hopefully.

Cheers,
aj
NN_il_Confusionario
2007-12-07 14:33:48 UTC
Permalink
Post by Anthony Towns
both required and base in the same list, so you have to look for the split
yourselve (zlibg1 and adduser atm), but that's not too hard hopefully.
Yes it is not _hard_, but it is exactly this sort of dependency hunting
that is uselessy time consuming, since for each _released_ debian (etch,
sarge, woody, ...) such a list is fixed and "already known"; having to
rediscover it each time is not the smartest thing.

In pratice, the fastest solution for me has been up to now to use
debootstrap, then install deborphan in the chroot to purge things. And
finally a tar of the "essential" chroot (without
var/cache/apt/archives/*.deb var/lib/apt/lists/*_{Release,Packages} and
so on). But then Murphy assures that sooner or later you will need a new
architecture or a new release or to install a machine without access to
the machine where the tar is saved ...

However, many tanks for your patch.
--
Chi usa software non libero avvelena anche te. Digli di smettere.
Informatica=arsenico: minime dosi in rari casi patologici, altrimenti letale.
Informatica=bomba: intelligente solo per gli stupidi che ci credono.
Agustin Martin
2007-12-10 13:18:01 UTC
Permalink
Post by Anthony Towns
ispell, dictionaries-common, iamerican, ibritish, wamerican
#416572: ibritish: Should not have priority standard

Only wamerican was originally intended for standard, because former
wamerican maintainer considered that a basic english wordlist should be
present in a system. dictionaries-common is standard only because is
needed by wamerican. I have been thinking at various ways to lower
the standard size, but am still undecided about the best choice, if
wamerican is to remain standard.

a) Splitting a new 'dictionaries-common-base' package containing
things meant only for wordlists (and so for wamerican) and some
things that are better here for simplicity.
b) Having a wamerican-standard package that is the same as normal
wamerican, but without the dictionaries-common integration stuff.
With proper conflicts/provides wamerican would replace it as soon
as another wordlist or an ispell/myspell/aspell dict is installed.

Still need to make some tests about this.
--
Agustin
Petter Reinholdtsen
2007-12-22 07:08:42 UTC
Permalink
[Anthony Towns]
Post by Anthony Towns
ispell, dictionaries-common, iamerican, ibritish, wamerican
[Agustin Martin]
Post by Anthony Towns
#416572: ibritish: Should not have priority standard
We now have aspell, myspell and hunspell as alternatives to ispell,
and it can be argued that all of them are better than ispell at
providing spell checking and recommendations for replacements.
Because of this, I believe it would be a good idea to drop ispell from
the list of standard packages, and the related packages too (i*, w*).

If we were to keep a spell checker as part of the default
installation, I would suggest using hunspell as it is most advanced
and I am told it support the most languages at the moment. The next
step would be to change all programs currently using ispell, aspell
and myspell by default to use hunspell instead. The only package I
use that are still using ispell is emacs. No idea how hard it would
be to update, but it would be a good thing to support for example
Hungarian and Nothern Sami spell checking in emacs. :)

Happy hacking,
--
Petter Reinholdtsen
brian m. carlson
2007-12-22 15:30:18 UTC
Permalink
Post by Petter Reinholdtsen
Because of this, I believe it would be a good idea to drop ispell from
the list of standard packages, and the related packages too (i*, w*).
Note that the w* packages provide word lists, which are important to
many programs. One could argue that a standard Unix system should have
a word list; at least, every Unix system I have used provides one.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Petter Reinholdtsen
2007-12-22 19:06:16 UTC
Permalink
[Brian M. Carlson]
Post by brian m. carlson
Note that the w* packages provide word lists, which are important to
many programs. One could argue that a standard Unix system should
have a word list; at least, every Unix system I have used provides
one.
OK. Which programs? I was only aware of ispell.

Happy hacking,
--
Petter Reinholdtsen
Lars Wirzenius
2007-12-22 19:29:08 UTC
Permalink
Post by Petter Reinholdtsen
[Brian M. Carlson]
Post by brian m. carlson
Note that the w* packages provide word lists, which are important to
many programs. One could argue that a standard Unix system should
have a word list; at least, every Unix system I have used provides
one.
OK. Which programs? I was only aware of ispell.
Anagram generators such as an, perhaps?
Russ Allbery
2007-12-22 20:20:19 UTC
Permalink
Post by Petter Reinholdtsen
[Brian M. Carlson]
Post by brian m. carlson
Note that the w* packages provide word lists, which are important to
many programs. One could argue that a standard Unix system should
have a word list; at least, every Unix system I have used provides
one.
OK. Which programs? I was only aware of ispell.
Any program that needs a source of words for some reason, or even just
users. One of the users I support picks machine names to fit a naming
scheme of first letter and word length by grepping /usr/share/dict/words.
I have test suites that use the word list as input to test hash table
routines. It's a quick way to answer trivia questions or search for
proper names. Etc.

It's not a set of applications that's horribly compelling in terms of core
system functionality, but it's one of those things that's Always Been
There and hence is surprising if it's not.

See previous thread about old Unix users and what we expect. :)
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Petter Reinholdtsen
2007-12-22 22:49:05 UTC
Permalink
[Russ Allbery]
Post by Russ Allbery
See previous thread about old Unix users and what we expect. :)
Well, some old unix users might expect it, but I've been using Unix
and friends since I started with HP-UX 9 in 1992, and I do not expect
word lists to be installed by default. :)

Lets move to the most advanced spell checker, hunspell, and drop
ispell and friends as a package to install in the base system. :)

Happy hacking,
--
Petter Reinholdtsen
Manoj Srivastava
2007-12-24 17:55:38 UTC
Permalink
Post by Petter Reinholdtsen
[Russ Allbery]
Post by Russ Allbery
See previous thread about old Unix users and what we expect. :)
Well, some old unix users might expect it, but I've been using Unix
and friends since I started with HP-UX 9 in 1992, and I do not expect
word lists to be installed by default. :)
I have been doing so since '85, and I do expect to find the word
lists. At this point we just have warring anecdotes; perhaps we should
be looking for _data_ before we change standard?
Post by Petter Reinholdtsen
Lets move to the most advanced spell checker, hunspell, and drop
ispell and friends as a package to install in the base system. :)
We could add hunspell, if it is indeed better. I am not sure
the case has been made for dropping ispell.

manoj
--
"Don't get married. Find a woman you hate and buy her a house." anon
Manoj Srivastava <***@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Bernhard R. Link
2007-12-23 13:05:41 UTC
Permalink
Post by Petter Reinholdtsen
Post by brian m. carlson
Note that the w* packages provide word lists, which are important to
many programs. One could argue that a standard Unix system should
have a word list; at least, every Unix system I have used provides
one.
OK. Which programs? I was only aware of ispell.
I thought ispell would only use the i* packages and not the w* packages.
To enhance the list of packages needing w* packages, the cracklib
packages (like libpam-cracklib) also use it to make sure you are not
using a known word as password.

Hochachtungsvoll,
Bernhard R. Link
Agustin Martin
2007-12-23 18:33:49 UTC
Permalink
Post by Bernhard R. Link
Post by Petter Reinholdtsen
Post by brian m. carlson
Note that the w* packages provide word lists, which are important to
many programs. One could argue that a standard Unix system should
have a word list; at least, every Unix system I have used provides
one.
OK. Which programs? I was only aware of ispell.
I thought ispell would only use the i* packages and not the w* packages.
ispell has a lookup command that allows you to look in a plain wordlist
for words matching a regexp while you are spell-checking. Both can be in
a different language. It is something like look, but allowing regexps.
Post by Bernhard R. Link
To enhance the list of packages needing w* packages, the cracklib
packages (like libpam-cracklib) also use it to make sure you are not
using a known word as password.
Adding look to the lists of commands that can use a wordlist.
--
Agustin
Manoj Srivastava
2007-12-24 17:53:17 UTC
Permalink
Post by Petter Reinholdtsen
[Brian M. Carlson]
Post by brian m. carlson
Note that the w* packages provide word lists, which are important to
many programs. One could argue that a standard Unix system should
have a word list; at least, every Unix system I have used provides
one.
OK. Which programs? I was only aware of ispell.
Well, I am not a program, but I often use /usr/share/dict/words
(I have not yet been able to train my fingers not to look for
/usr/dict/words) directly, and also as test data for code snippets i
write.

We should not change out aspects of the system that users have
come to depend on, if it can be helped.

manoj
--
Exercise caution in your daily affairs.
Manoj Srivastava <***@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Agustin Martin
2007-12-23 18:10:37 UTC
Permalink
Post by Petter Reinholdtsen
[Anthony Towns]
Post by Anthony Towns
ispell, dictionaries-common, iamerican, ibritish, wamerican
[Agustin Martin]
Post by Anthony Towns
#416572: ibritish: Should not have priority standard
We now have aspell, myspell and hunspell as alternatives to ispell,
and it can be argued that all of them are better than ispell at
providing spell checking and recommendations for replacements.
Because of this, I believe it would be a good idea to drop ispell from
the list of standard packages, and the related packages too (i*, w*).
What I meant in the rest of my mail was that ispell should already be out
of the standard packages (as well as iamerican, ibritish and wbritish),
and the same for any other spellchecker like aspell or hunspell.

Only wamerican was intended to be part of standard. dictionaries-common is
also part of standard because wamerican needs it for wordlists integration
into Debian. This is something I would like to improve, but I am still
unclear about how.
--
Agustin
Manoj Srivastava
2007-12-24 17:50:34 UTC
Permalink
Post by Petter Reinholdtsen
[Anthony Towns]
Kind of reviving an old thread, but anyway: It also includes, but
ispell, dictionaries-common, iamerican, ibritish, wamerican
[Agustin Martin]
#416572: ibritish: Should not have priority standard
We now have aspell, myspell and hunspell as alternatives to ispell,
and it can be argued that all of them are better than ispell at
providing spell checking and recommendations for replacements.
Because of this, I believe it would be a good idea to drop ispell from
the list of standard packages, and the related packages too (i*, w*).
Are these packages a drop in replacement for ispell?
Post by Petter Reinholdtsen
If we were to keep a spell checker as part of the default
installation, I would suggest using hunspell as it is most advanced
and I am told it support the most languages at the moment. The next
step would be to change all programs currently using ispell, aspell
and myspell by default to use hunspell instead. The only package I
use that are still using ispell is emacs. No idea how hard it would
be to update, but it would be a good thing to support for example
Hungarian and Nothern Sami spell checking in emacs. :)
I suggest we have a look at how many other packages are
impacted, and what it would take to effect these changes, before the
decision is taken to drop ispell.

manoj
--
Administration: An ingenious abstraction in politics, designed to
receive the kicks and cuffs due to the premier or president.-- Ambrose
Bierce
Manoj Srivastava <***@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Petter Reinholdtsen
2007-12-25 11:17:52 UTC
Permalink
[Manoj Srivastava]
Post by Manoj Srivastava
Are these packages a drop in replacement for ispell?
None of the spell checkers are drop in replacements for the others.
Each program need to have support for ispell, aspell, myspell and/or
hunspell. This is why I want us to try to get as many packages as
possible to switch to hunspell, to make it possible to drop ispell
completely.
Post by Manoj Srivastava
I suggest we have a look at how many other packages are impacted,
and what it would take to effect these changes, before the decision
is taken to drop ispell.
Well, I would not suggest to drop ispell, so we do not have to check
the effect of dropping it for my sake. Dropping ispell will take too
long and slow down the process of changing the default spell checker
without any advantages.

What I do suggest is to change the list of default packages and dropp
the spell checker from that list, and announce our intention to move
to hunspell as the default spell checker used in Debian. The packages
that still use ispell, aspell and myspell will still work until we are
able to get them to switch to huspell, and each will have to be
changed individually to switch to hunspell. For some it is a compile
flag, for others it is a configuration setting, and for others it
require code changes.

This is independent of the question on whether to install a word list
by default. I have nothing against installing a word list by default,
as long as its size isn't too huge.

Happy hacking,
--
Petter Reinholdtsen
Manoj Srivastava
2007-12-26 02:39:03 UTC
Permalink
Post by Petter Reinholdtsen
[Manoj Srivastava]
Post by Manoj Srivastava
Are these packages a drop in replacement for ispell?
None of the spell checkers are drop in replacements for the others.
Each program need to have support for ispell, aspell, myspell and/or
hunspell. This is why I want us to try to get as many packages as
possible to switch to hunspell, to make it possible to drop ispell
completely.
Post by Manoj Srivastava
I suggest we have a look at how many other packages are impacted, and
what it would take to effect these changes, before the decision is
taken to drop ispell.
Well, I would not suggest to drop ispell, so we do not have to check
the effect of dropping it for my sake. Dropping ispell will take too
long and slow down the process of changing the default spell checker
without any advantages.
What I do suggest is to change the list of default packages and dropp
the spell checker from that list, and announce our intention to move
to hunspell as the default spell checker used in Debian. The packages
that still use ispell, aspell and myspell will still work until we are
able to get them to switch to huspell, and each will have to be
changed individually to switch to hunspell. For some it is a compile
flag, for others it is a configuration setting, and for others it
require code changes.
Umm. The part that I dislike about this is that we have an
installed base of users, and people like me who use emacs and for whom
the default installation of emacs just works. When installing new
Debian boxes I just install emacs and the standard install.

Now, we should not make it so that people who used to just do a
routine install now have a non-working setup. So, if you want things
to be dropped from standard, please think about a transition strategy
where people would not have a broken setup when they upgrade, or do a
fresh install.

One solution, for instance, would be to modify dependent
packages like emacs to use the new standard, and make sure thay things
do not break for our users.

Just adding things to NEWS is not good enough, since the emacs
user might not be the vi using sysadmin. Not breaking user setup is
something we have a reputation for, and that is a good thing.

manoj
--
"Laughter is the closest distance between two people." -Victor Borge
Manoj Srivastava <***@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Luca Capello
2007-12-27 01:54:34 UTC
Permalink
Hi all!
Post by Petter Reinholdtsen
[Manoj Srivastava]
Post by Manoj Srivastava
Are these packages a drop in replacement for ispell?
None of the spell checkers are drop in replacements for the others.
Each program need to have support for ispell, aspell, myspell and/or
hunspell. This is why I want us to try to get as many packages as
possible to switch to hunspell, to make it possible to drop ispell
completely.
It seems that I cannot find a comparison of the differences spell
checkers. Please, could you enlighten me on why hunspell should be a
better default one?

Thx, bye,
Gismo / Luca
Luca Capello
2007-12-27 01:56:13 UTC
Permalink
Hi all (again)!
Post by Luca Capello
Post by Petter Reinholdtsen
[Manoj Srivastava]
Post by Manoj Srivastava
Are these packages a drop in replacement for ispell?
None of the spell checkers are drop in replacements for the others.
Each program need to have support for ispell, aspell, myspell and/or
hunspell. This is why I want us to try to get as many packages as
possible to switch to hunspell, to make it possible to drop ispell
completely.
It seems that I cannot find a comparison of the differences spell
^^^^^^^^^^^^^^^^^
This should have been "differences BETWEEN spell checkers" or "DIFFERENT
spell checkers", as you prefer ;-)

Thx, bye,
Gismo / Luca
Petter Reinholdtsen
2007-12-28 12:30:02 UTC
Permalink
[Luca Capello]
Post by Luca Capello
It seems that I cannot find a comparison of the differences spell
checkers. Please, could you enlighten me on why hunspell should be
a better default one?
I can only refer to the knowledge I have gotten from those I know that
work on spell checkers. The features of spell checkers is normally
how well they handle word transformations, concatenations and
proposals. ispell, aspell and myspell are ok for languages where the
main transformation is adding word endings (like cat -> cats), and not
good with languages with more complex transformations (er -> var), and
completely useless for languages with very complex transformations
(got no example, but I know Nothern Sami have word transformations
based on the words around changes. When it comes to concatenations, I
am not sure which of these are doing a good job, but I believe aspell,
myspell and hunspell does a better job than ispell. As for proposals,
aspell include rules on common misspellings and letters that sound the
same as other letters, and uses this to calculate likely proposals for
misspelled words. ispell do not. I believe myspell and hunspell does
the same.

So the main differentiating factor is how well the spell checker
handle word transformation, and I am told that hunspell is a huge
improvement for languages with complex transformation rules compared
to ispell, aspell and myspell.

I found
<URL:http://www.divvun.no/doc/proof/spelling/X-spell/index.html> on
the pages for the Nothern Sami spell check, which provide some more
information.

Happy hacking,
--
Petter Reinholdtsen
Agustin Martin
2007-12-29 16:22:13 UTC
Permalink
Post by Luca Capello
Hi all!
Post by Petter Reinholdtsen
[Manoj Srivastava]
Post by Manoj Srivastava
Are these packages a drop in replacement for ispell?
None of the spell checkers are drop in replacements for the others.
Each program need to have support for ispell, aspell, myspell and/or
hunspell. This is why I want us to try to get as many packages as
possible to switch to hunspell, to make it possible to drop ispell
completely.
It seems that I cannot find a comparison of the differences spell
checkers. Please, could you enlighten me on why hunspell should be a
better default one?
I do not have much experience with hunspell, so take everything I write
about hunspell with extreme care,

Regarding other spell-checkers, the only advantages ispell currently has
over the others are probably a lower memory use and an easier support for
things like TeX encoding and shorthanded TeX encoding (using 'a instead
of \'a). Disadvantages are many.

Regarding aspell its main advantage (besides the suggestion algorithms
and soundslike support) is the supports for filters, which should make
easier spell-checking of special text files (in etch where I write now:
context, email, sgml, texinfo, debctrl, nroff and tex).

hunspell advantages are mostly:
* On the fly creation of hash tables from plain text dict files while
aspell uses a pre-built binary file for loading efficiency. This is
not a big problem for Debian users, since most aspell dicts build the
binary hash tables from postinst and the dict itself is arch all. This
can however be an hunspell efficiency disadvantage for (hunspell still
unsupported here) emacs ispell.el, when you are switching between
different buffers in different languages and require full rebuilding
each time.
* Handling of composed synthetic and agglutinative languages. One side
note here, Kevin Atkinson (aspell upstream) recently reported in
aspell-user list that some of the hunspell code was merged into aspell
CVS. Not sure if all hunspell functionalities will be available, but
at least some of hunspell features will be present in next aspell
release.
* Portability? Not sure if this is still an issue, but older myspell
seemed to be a bit more portable than aspell at that time.

... Write your additions ...

So, I am not sure about which spellchecker should be the default one, aspell
or hunspell, just I would have liked all the new code being written against
the same program.
--
Agustin
Agustin Martin
2007-12-29 16:22:28 UTC
Permalink
Post by Petter Reinholdtsen
If we were to keep a spell checker as part of the default
installation, I would suggest using hunspell as it is most advanced
and I am told it support the most languages at the moment. The next
step would be to change all programs currently using ispell, aspell
and myspell by default to use hunspell instead. The only package I
use that are still using ispell is emacs.
A side note here, emacs+ispell.el can also use aspell
--
Agustin
Marc 'HE' Brockschmidt
2007-12-10 16:38:50 UTC
Permalink
Post by Anthony Towns
Post by Marc 'HE' Brockschmidt
I believe it to be one of the more important bits of a standard Unix
*desktop* installation - but this just reminds me of the fact that I'm
quite uncomfortable with keeping a system like package priorities around
for much longer. Diverging use-cases (like in this case) show that one
definition of "standard" isn't really helpful anymore.
Haven't we more or less already moved away from priorities as meaning
anything particularly important?
Yes, but we still enforce the formal requirements.
Post by Anthony Towns
required/essential -- stuff that can't be removed: libc, dpkg, etc
important -- the rest of base, stuff necessary to bootstrap and
recover a usable and useful system
I have to admit that I don't see why we can't merge those two. At the
moment, these packages are in required without being marked as
essential:
debconf debconf-i18n dselect e2fslibs gcc-4.2-base initscripts libacl1
libattr1 libblkid1 libc6 libcap1 libcomerr2 libdb4.3 libdevmapper1.02.1
libgcc1 liblocale-gettext-perl libncurses5 libpam-modules libpam-runtime
libpam0g libselinux1 libsepol1 libslang2 libss2 libstdc++6
libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libuuid1
lsb-base makedev mawk passwd procps sysv-rc tzdata zlib1g

I don't see what makes those required-but-not-important or why the
packages in important aren't required.
Post by Anthony Towns
optional -- all the good software in the world
extra -- obscure stuff
All the really important questions are which bits of "optional" (and
occassionally extra) are useful for a given user.
I'm not sure if there's any point to continuing to try to make sure that
nothing >= optional conflicts with anything else >= optional.
I don't see the point of doing that anymore. On i386, sid has 3123
packages in extra and 18178 in optional. The policy says "This is all
the software that you might reasonably want to install if you didn't
know what it was and don't have specialized requirements. This is a much
larger system and includes the X Window System, a full TeX distribution,
and many applications." about optional. Over 18000 binary packages don't
sound like that.
Post by Anthony Towns
at, bc, dc, lsof, file, less, sharutils, strace
dnsutils, ftp, host, ssh, mtr-tiny, finger, w3m, whois
doc-debian, doc-linux-text
exim, mailx, mutt, procmail, mime-support, mpack
gettext-base, locales
pciutils
perl (not just perl-base), python
reportbug
selinux policy
That seems a pretty reasonable set of functionality to put on all Debian
boxes (unless the admin specifically says otherwise), afaics.
Well, moving away from exim to nullmailer or something like that has
been discussed a few times. procmail is pretty weird in there, as only
few people still use procmail. Just like w3m or mutt - those may look
reasonable for a Unix admin, but a standard user will never touch them.

Marc
--
BOFH #339:
manager in the cable duct
Michael Banck
2007-12-10 18:53:52 UTC
Permalink
Post by Marc 'HE' Brockschmidt
Post by Anthony Towns
at, bc, dc, lsof, file, less, sharutils, strace
dnsutils, ftp, host, ssh, mtr-tiny, finger, w3m, whois
doc-debian, doc-linux-text
exim, mailx, mutt, procmail, mime-support, mpack
gettext-base, locales
pciutils
perl (not just perl-base), python
reportbug
selinux policy
That seems a pretty reasonable set of functionality to put on all Debian
boxes (unless the admin specifically says otherwise), afaics.
Well, moving away from exim to nullmailer or something like that has
been discussed a few times. procmail is pretty weird in there, as only
few people still use procmail. Just like w3m or mutt - those may look
reasonable for a Unix admin, but a standard user will never touch them.
I think we should move most of that into a "Unix" (or "GNU" or whatever)
task, that old-timers can install.


Michael
Steve Langasek
2007-11-12 03:52:47 UTC
Permalink
Post by Russ Allbery
Post by Steve Langasek
- Should we consider raising the priority of cupsys to standard, to take the
place of lpr as an available-by-default printing system on stock installs?
The last time I looked at CUPS, it was massively more complicated than lpr
and involved dubious things like running daemons that listened on network
ports for user configuration. Is that still the case?
CUPS still supports configuration via the web interface on port 631, yes; by
default the daemon only listens on localhost, though, and there are other
config tools that don't rely on the web interface for managing
printers/queues in a desktop setting.

It is more complicated than lpr, for sure. That's a big reason why I don't
particularly care for the implementation. Nevertheless, CUPS has
effectively won out as the standard printing service on Linux.
Post by Russ Allbery
Also, do we really need *any* printing system as priority: standard? It's
not clear to me that printing is still really part of a standard Unix
installation, even for desktop users (and it definitely isn't for
servers).
Perhaps not. It did seem to me like something that we would want available
by default, and that would in any case be consistent with past practice.
After all, this isn't so much a question of installing a "print server"
task, the cupsys package is these days the package most users will want
installed even for local printing.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
***@debian.org http://www.debian.org/
Christian Perrier
2007-11-12 06:13:21 UTC
Permalink
Post by Steve Langasek
A few years back, Samba upstream began using CUPS as the default printing
standard (or higher), so I patched the Samba packages in Debian to default
to BSD printing instead of CUPS.
Today the circumstances have changed. It seems that lpr was demoted to
optional sometime before the etch release, putting it on equal footing with
cupsys in that regard, and CUPS itself has IME improved markedly since the
time that decision was made (I'm personally still not fond of the
implementation, but at least it does a better job of talking to printers for
- Is there any remaining reason why the Samba maintainers shouldn't drop
this patch, switching to CUPS as the default print system?
I think that no objections to this was made so we might drop the
patch. DO you agree, Steve, or should we wait longer for other comments?

I vote for dropping the patch which is yet another step towards having
samba in Debian as close as possible as its upstream.
Post by Steve Langasek
- Should we consider raising the priority of cupsys to standard, to take the
place of lpr as an available-by-default printing system on stock installs?
Here, we clearly don't seem to have any consensus, but anyway, *this*
is not in samba maintainers hands, of course.
Teemu Likonen
2007-12-28 16:13:57 UTC
Permalink
(I just subscribed to this list and tried to construct the References
field manually. I Hope it won't broke threads.)


Petter Reinholdtsen wrote:

[Luca Capello]
Post by Petter Reinholdtsen
Post by Luca Capello
It seems that I cannot find a comparison of the differences spell
checkers. Please, could you enlighten me on why hunspell should be
a better default one?
I can only refer to the knowledge I have gotten from those I know that
work on spell checkers. The features of spell checkers is normally
how well they handle word transformations, concatenations and
proposals.
You made good points on what spell-checkers are _technically_ better.
I don't know them very well myself but I understand that many of them
are not suitable for synthetic and agglutinative languages like
Finno-Ugric languages. Hunspell seems to be, though, as it was
originally designed for Hungarian.

(For Finnish we even need a completely unique system Voikko which is
used through libvoikko1 and programs depending on it, see 'aptitude
search ~Dlibvoikko1'.)

But I think this is not the main point when deciding the _default_
spell-checker for Debian. A spell-checker may be technically superior to
others but if it's not supported by many languages (i.e. no dictionary
packages) it may not be good default and standard install. I have no
opinion about this myself. Finnish users use Voikko anyway and it is
installed through the Finnish environment task (or desktop task, I don't
remember). I think the question of default spell-checker is more
practical than technical; it has to be considered from supported
languages' point of view.
Petter Reinholdtsen
2007-12-29 09:50:25 UTC
Permalink
[Teemu Likonen]
I think the question of default spell-checker is more practical than
technical; it has to be considered from supported languages' point
of view.
I agree, but I believe all are fairly equivalent there. At least I
know that for the simple languages like Norwegian Bokmål and Nynorsk,
it is fairly simple to generate a spell check data file for ispell,
aspell, myspell and hunspell from the same data source. See the
norwegian debian package for the setup.

So I expect other languages to do the same, but have not checked. We
need to work to assure that the set of languages supported by the
default and recommended spell checker is as good or better than with
ispell when we switch.

Happy hacking,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Loading...