The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: quick install method (was Re: Deity project schedule problems)

As a preamble, I'd like to say that this mail is meant to clarify
a set of suggestions.  I certainly don't mean to push.

Craig Sanders wrote:
> On Sun, 21 Sep 1997, Richard Braakman wrote:
[Making the sets pluggable...]
>
> i disagree. i think that it's not very hard at all (either to code or
> for the user to choose) and there is a lot of corresponding benefit.

Well, there's only one way to find out :)  If it's easy, then it's
easy.  I certainly agree that there is benefit.
 
> > I think a simple "minimal", "average", or "complete" choice would
> > be better.  And we already have something like that in the package
> > organisation.  Some (edited) quotes from the policy manual:
[SNIP]

> my feeling is that:
> 
> a) the user will say "WTF! i have no idea what 'important' or 'standard'
> or 'optional' means". e.g is elm 'standard'? or is it 'optional'? what
> about gcc? is that 'important' or not? what is "reasonable to expect"?
>
> in other words, i think it's too simple....it jumps from a situation
> of having far too much information to make a choice, to having far too
> little.

Hm, I may have been unclear.  I meant to suggest that the existing
`standard' and `optional' priorities be used to construct the
"minimal" and "complete" sets, and that the quotes from the policy
manual be used to describe them.  Note that I edited the quotes for
brevity; the policy manual does mention where emacs and TeX and X go.

> b) you wont get developers to agree on what's 'standard' and 'optional'
> either. some will say mutt should be standard, others will say mutt is
> dogs' droppings and elm is the standard mailer. ditto for vi vs emacs
> (only about 100 times hotter flames), sendmail vs smail, "dev tools are
> 'standard'" vs "no they're not!".

Well, my whole point is that we have already made these decisions :)
elm-me+ is `standard', mutt is `optional'.  smail is `important',
sendmail is `extra'.  nvi is `important', ae is `required', emacs is
`standard'.  The C/C++ development tools are `standard', and the
others tend to have the same priority as the packages for which they
are development tools.

> that's why i think that there should be around 5 (perhaps as many as
> 10 or so) sets grouped roughly by function...network clients, network
> servers, X, development stuff, games, etc.

Network clients and servers are currently combined in one package
(netstd), so that would be hard to separate.

> > Currently `standard' is the group that can be selected automatically,
> > and I think it's what I would call "minimal".  If you add in everything
> > from `optional' you get what I would call "complete".  I think that what's
> 
> trouble is that YOUR "complete" is probably completely different from MY
> "complete".

Well, no.  Then it wouldn't be "complete" :)  The packages in `extra' are
there for a reason.  Policy quote:
  They conflict with others with higher priorities, or are only likely
  to be useful if you already know what they are or have specialised
  requirements.

> small is good.  not everyone has a 2gb drive dedicated to linux.  many
> newbies are just trying it out for the first time on a smallish partition.
> people who want more than the 'bare minimum' can always use dpkg or dselect
> to install extra stuff.

On the other hand, many people just bought a big disk and just want to
install something that works.  We should be able to accommodate both
types.

I think that for most users it's easier to install everything and
later remove unused packages when they run out of space, than to 
have to hunt (at install time) for the packages they will need.

(I realise that that attitude is abhorrent to most Debian developers.
That's _why_ they're Debian developers, rather than end-users :-)

> BTW, i have no problem at all with this discussion being moved over to
> debian-devel where it probably belongs.

Neither do I, but I checked and debian-devel does not yet know about
Deity being behind schedule.  (Except for a paragraph where Bruce
Perens said "salvaging the Deity project").

Richard Braakman


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .