Re: Priorities

2000-10-10 Thread Anthony Towns
debian-boot: This is diverging into a discussion of task- packages. It's
probably reasonable to keep discussion on -policy rather than duplicate it
on both lists, I guess.

On Mon, Oct 09, 2000 at 03:56:15PM -0500, Steve Greenland wrote:
 As far as mutliple preferred packages, my intent is that such a phrase
 is an oxymoron; the whole *idea* is help the users select one particular
 implementation out of several possibilities. Basically, we'd be saying
 If you're not sure which {web-server, whatever} to install, try this
 one first.

Well, which of emacs or vi should be the preferred editor? Or should
nano, joe, jed, or something else be the preferred editor? Why shouldn't
we say try emacs  vi, and see what you like, otherwise, choose some
other one? Why is that worse than saying try emacs, and see if you
like it, otherwise choose some other one?

There're technical reasons why we can only recommend one MTA conveniently,
which means we have to limit ourselves to one MTA for people to try by
default, so we do. But there doesn't seem any huge reason to limit other
things to just a single best possibility.

 It's not the same as task packages, because the intent of those (as
 I understand it) is to group various packages that work together. I'm
 also bothered (a little) by the task-webserver-roxen (why is there no
 task-webserver?), in that it doesn't offer much guidance (because it
 implies the existence of t-w-apache, t-w-boa, etc.).

I don't really understand task packages. I'd assume that they're there
to make it easy for people to do some particular common tasks (setup a
desktop environment, interact with your computer in japanese, play music,
do 3d graphics, program).

It seems to me like it might be bing abused somewhat as an excuse to
advertise particular groups of packages. task-webserver-roxen, and
task-x-window-system come to mind as being more an excuse to group a
bunch of packages together than really focussing on being something
useful for the prospective user, for example. OTOH, I want a useful X
environment isn't an unreasonable task.

Actually, going a bit further on that idea.

The *task* is really usable 2d windowing environment for accessing
programs, it's not kde, or gnome, or xlib, or motif. Is it really
sensible to have the choice between the various windowing toolkits
made here?  Would it be better/possible to have a task-desktop that
included both gnome and kde, and the best apps from both, and just let
the user use them?  Obviously the packager would have to make a choice
amongst xdm, gdm and kdm, but that doesn't seem unreasonably difficult.

Going through the task packages in my available file:

c-dev, c++-dev, python-dev, tcltk-dev, objc-dev, fortran
- i want to program in foo
debian-devel
- i want to create debian packages
sgml, tex
- i want to write documents in foo
german, chinese-s, chinese-t, japanese, spanish, polish
- i (or some of my users) speak foo
games
- i want to play games on this computer
science
- i want to do science on this comuter (this seems a little too
  broad, but maybe no more so than games)
newbie-help
-  i'm a newbie and want to learn about unix ?

These seem like reasonable helper packages, that'll set up your system
to do something relatively complicated, relatively simply:

dns-server
news-server 
imap
parallel-computing-dev 
parallel-computing-node
database-pg (perhaps sql-database would be a better name)
samba (a more generic name would be more consistent, but maybe not better)

We also have a few my computer is a little different to others task- packages,
which probably make some sense:

laptop 
dialup 
dialup-isdn 

I don't see a point to:

python
- how do I know whether I'm going to write complicated apps or not?
gnome-games
- i just want to play games, i don't care what toolkit they use
tcltk
- how do i kow if i want to run tcltk programs? debian packages will
  install it if they need it, presumably the lsb will do likewise,
  and anything i buy will tell me what i need to install, surely?
debug
- if I'm going to be programming, I'm probably going to be debugging.
  if I'm not programming why would i be debugging?
devel-common
- C and C++ and Objective C are already covered with the specific
  tasks, what's the point?
doc
- eh?? i have to go out of my way to get General documentation??
python-web
- a general i want to work on interactive web sites task would make
  sense to me (one that included, presumably, a free java, and zope,
  and tomcat, and tools to do cgi in perl and python and whatever else)
  but just for pythn? apt-get install zope if that's what you want.

The following seem to be just random collections of packages:


Re: Priorities

2000-10-10 Thread Seth Arnold
* Anthony Towns aj@azure.humbug.org.au [001009 21:10]:
 Well, which of emacs or vi should be the preferred editor?

This is missing the biggest question of all -- which of the various Vi
clones should be THE vi Debian suggests?

Vim, of course.

:)



Bug#73620: Policy example about INSTALL is wrong

2000-10-10 Thread Manoj Srivastava
Hi,
Josip == Josip Rodin [EMAIL PROTECTED] writes:

 Josip Using install-sh while /usr/bin/install exists just wastes
 Josip time/resources of people who recompile (think 6 build
 Josip daemons), I don't see why shouldn't Policy recommend a more
 Josip rational method.

Becausepolicy is not a method for laying down the law on good
 practices (espescially since it can be then used to beat developers
 over the head with), since policy would baloon to an unwieldy
 size. Policy should be a minimal document; not everything has to be
 in policy. 

In this case I think the package developer should be allowed
 the discretion; they often know what is best for their package; and
 even otherwise a simle bug report would help resolve issues for
 particular packages.

Now, were you to try and get this included in the developers
 reference as a good thing(TM), I would be supportive.

manoj
-- 
 I am deeply CONCERNED and I want something GOOD for BREAKFAST!
Manoj Srivastava   [EMAIL PROTECTED]  http://www.debian.org/%7Esrivasta/
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Bug#73620: Policy example about INSTALL is wrong

2000-10-10 Thread Josip Rodin
On Tue, Oct 10, 2000 at 11:15:21AM -0500, Manoj Srivastava wrote:
  Josip Using install-sh while /usr/bin/install exists just wastes
  Josip time/resources of people who recompile (think 6 build
  Josip daemons), I don't see why shouldn't Policy recommend a more
  Josip rational method.
 
   Becausepolicy is not a method for laying down the law on good
  practices (espescially since it can be then used to beat developers
  over the head with), since policy would baloon to an unwieldy
  size. Policy should be a minimal document; not everything has to be
  in policy. 

Quoting Policy:

 Generally the following compilation parameters should be used:

CC = gcc
CFLAGS = -O2 -Wall # sane warning options vary between 
programs
LDFLAGS = # none
install -s # (or use strip on the files in debian/tmp)

 Note that by default all installed binaries should be stripped, either
 by using the `-s' flag to `install', or by calling `strip' on the
 binaries after they have been copied into `debian/tmp' but before the
 tree is made into a package.

I see nothing there that is a firm rule, everything is a recommendation, a
good practice. The install-sh script is a replacement for install(1) on
systems that don't have it, not the other way round. There is absolutely no
reason why would one want to use install-sh over install(1) on Debian
systems. If there was, it would be a bug in our install(1), and an important
one, in fact.

Yet there can be valid reasons why to use different compiler flags (general
and per-architecture optimizations, different warning levels, -ansi or
-pedantic, etc), or to call strip in some other place of the process
(there's no need to do additional stripping when upstream has a build system
that makes unstripped binaries in src/ and stripped in bin/ directory, etc).

Also, I was not suggesting adding a requirement of using install(1) over
install-sh, I just mentioned how it would make a nice suggestion, perhaps
even in a footnote. The Developers' Reference could contain this, yes, but
then it would be logical to also move the above paragraph from Policy, along
with anything similar.

-- 
Digital Electronic Being Intended for Assassination and Nullification