On Mon, Dec 10, 2007 at 05:38:50PM +0100, Marc 'HE' Brockschmidt wrote:
> > 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
> I have to admi
Anthony Towns <[EMAIL PROTECTED]> writes:
> On Sun, Nov 11, 2007 at 07:12:35PM +0100, Marc 'HE' Brockschmidt wrote:
>> 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
On Fri, Dec 07, 2007 at 12:01:43AM +1000, Anthony Towns wrote:
> Kind of reviving an old thread, but anyway:
> It also includes, but afaics, probably doesn't need to (anymore):
>
> ispell, dictionaries-common, iamerican, ibritish, wamerican
#416572: ibritish: Should not have priority standa
On Thu, Dec 06, 2007 at 11:03:08PM -0600, Manoj Srivastava wrote:
> 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
> So -- how many of the standard unix commands
Anthony Towns <[EMAIL PROTECTED]> writes:
> On Thu, Dec 06, 2007 at 05:09:36PM -0600, Manoj Srivastava wrote:
>> On Thu, 06 Dec 2007 13:34:10 -0800, Ben Pfaff <[EMAIL PROTECTED]> said:
>> > I use "time" in benchmarking scripts.
>> I do not find the built in time to be a substitute for th
On Fri, 7 Dec 2007 12:28:55 +1000, Anthony Towns <[EMAIL PROTECTED]> said:
> On Thu, Dec 06, 2007 at 05:09:36PM -0600, Manoj Srivastava wrote:
>> On Thu, 06 Dec 2007 13:34:10 -0800, Ben Pfaff <[EMAIL PROTECTED]>
>> said:
>> > I use "time" in benchmarking scripts.
>> I do not find the built in tim
On Thu, Dec 06, 2007 at 05:09:36PM -0600, Manoj Srivastava wrote:
> On Thu, 06 Dec 2007 13:34:10 -0800, Ben Pfaff <[EMAIL PROTECTED]> said:
> > 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:
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> On Thu, 06 Dec 2007 13:34:10 -0800, Ben Pfaff <[EMAIL PROTECTED]> said:
>
>> 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
On Thu, 06 Dec 2007 13:34:10 -0800, Ben Pfaff <[EMAIL PROTECTED]> said:
> 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
Bernd Zeimetz <[EMAIL PROTECTED]> writes:
>> 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.
> Alt
> 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, i
"brian m. carlson" <[EMAIL PROTECTED]> writes:
> On Fri, Dec 07, 2007 at 04:51:29AM +1000, Anthony Towns wrote:
>>On Thu, Dec 06, 2007 at 07:42:06AM -0800, Russ Allbery wrote:
>>> Anthony Towns <[EMAIL PROTECTED]> writes:
>>> > time (???)
>>> Likewise. time is a standard Unix program.
>>
>>And
On Fri, Dec 07, 2007 at 04:51:29AM +1000, Anthony Towns wrote:
On Thu, Dec 06, 2007 at 07:42:06AM -0800, Russ Allbery wrote:
Anthony Towns <[EMAIL PROTECTED]> writes:
>time (???)
Likewise. time is a standard Unix program.
And which is a built-in on bash, tcsh and zsh, so doesn't seem terr
Anthony Towns <[EMAIL PROTECTED]> writes:
> On Thu, Dec 06, 2007 at 07:42:06AM -0800, Russ Allbery wrote:
>>> 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."
> Wh
On Thu, Dec 06, 2007 at 10:26:11AM -0600, Manoj Srivastava wrote:
> > 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 achi
On Thu, Dec 06, 2007 at 07:42:06AM -0800, Russ Allbery wrote:
> Anthony Towns <[EMAIL PROTECTED]> writes:
> > It also includes, but afaics, probably doesn't need to (anymore):
> > ispell, dictionaries-common, iamerican, ibritish, wamerican
> > m4, texinfo (???)
> texinfo possibly for info a
On Fri, 7 Dec 2007 00:01:43 +1000, Anthony Towns <[EMAIL PROTECTED]> said:
> 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
Packages which are require
Anthony Towns <[EMAIL PROTECTED]> writes:
> It also includes, but afaics, probably doesn't need to (anymore):
>
> 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
Buddha Buck <[EMAIL PROTECTED]> writes:
> if the task-* packages are intended solely for the
> purview of tasksel, why put them in the main
> Packages.gz file? Why not distribute the dependency
> information as part of the tasksel package?
Because that's a huge pain in the butt, doesn't scale, a
23 Oct 2000 08:15:07 -0400,
on Re: Priorities,
Ben Collins <[EMAIL PROTECTED]> wrote:
> I think the task-* packages can be solved pretty easily with some
> guidelines like:
>
> Task packages can define different levels of installation. The
> tasksel pro
Hi
Ben Collins schrieb:
> Task packages can define different levels of installation. The
> tasksel program will follow these rules for each case:
>
> - Minimum, installs everything that the task-* package Depends on
> - Standard, installs everything in Minimum, plus packag
>
> Now, there are some related problems happening. One big one is the
> fact that "Recommends" and "Suggests" have lost their usefulness
> since apt-get came on the scene. I venture to suggest that several of
> the inappropriate task-* packages exist purely to remedy this. If,
> e.g., the Roxe
On Wed, Oct 18, 2000 at 01:05:28PM -0700, Chris Waters wrote:
>
> ~ $ grep-available -P roxen -sPackage|wc -l
>70
I think this is a different problem. There's no reason for every little
Roxen module to be a separate package.
Richard Braakman
On Sat, Oct 14, 2000 at 10:03:08PM -0400, Adam Di Carlo wrote:
> Sorry, I'm not on debian-policy, but since I was one of the ones who
> lobbied for task packages, just a few random thoughts.
(Cc'ed)
> > python
> > - how do I know whether I'm going to write "complicated" apps or not?
> I d
At 11:39 AM 10/19/00 -0700, Chris Waters wrote:
On Wed, Oct 18, 2000 at 10:46:36AM -0400, Deephanphongs, David wrote:
> If task packages can provide choice, why not let them? The
> task-gnome-desktop (or something like that) package was helpful to
> me when I wanted to install gnome, since it's
On Wed, Oct 18, 2000 at 10:46:36AM -0400, Deephanphongs, David wrote:
> If task packages can provide choice, why not let them? The
> task-gnome-desktop (or something like that) package was helpful to
> me when I wanted to install gnome, since it's made up of
> half-a-dozen packages.
Yes, but the
On Tue, Oct 17, 2000 at 12:06:58PM -0700, Joey Hess wrote:
> Yes, task-webserver-roxen should not exist. I have written about this
> before. "I want a web server" is a suitable task, "I want web server
> foo" is not.
I think the problem we're seeing is this: the 'task-' package
namespace is magi
While I mostly agree with Adam, there's one nit I'd like to pick:
On 14-Oct-00, 21:03 (CDT), Adam Di Carlo <[EMAIL PROTECTED]> wrote:
> > * browsing the web (without having to download plugins all the
> > time, having java support, etc)
>
> Well, we do have virtual packages for this.
>
Peter S Galbraith schrieb:
> I don't understand. If you remove task-doc from the list of task
> packages that users can easily pick from, they _will_ have to go
> out of their way to get them installed individually as packages.
Well, may be renaming it to eg task-newbie would be another
solution.
> From: Joey Hess [mailto:[EMAIL PROTECTED]
>
> Anthony Towns wrote:
> > 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?
Joey Hess wrote:
> Anthony Towns wrote:
>
> > doc
> > - eh?? i have to go out of my way to get "General documentation"??
>
> I think I agree with all of these. We should file bugs to get them
> removed.
I don't understand. If you remove task-doc from the list of task
packages that user
Anthony Towns wrote:
> 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).
Right. Have you done a pota
Sorry, I'm not on debian-policy, but since I was one of the ones who
lobbied for task packages, just a few random thoughts.
Anthony Towns writes:
> 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
> de
* Anthony Towns [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.
:)
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
On 09-Oct-00, 13:57 (CDT), Anthony Towns wrote:
> On Mon, Oct 09, 2000 at 12:13:47PM -0500, Steve Greenland wrote:
> >
> > preferred: The Debian preferred implementation of a common service that
> > has multiple implementations (e.g. webservers, SMTP, mp3 players, etc.)
>
> Couldn't that just g
And some of the task- packages should logically conflict with each other,
because they depend or reccomend conflicting packages.
For example, if task-gnome-desktop depended on gdm (which it doesn't
according to my apt-cache), then it and task-kde should be made to
conflict because gdm and kdm con
On Tue, Oct 10, 2000 at 05:18:05AM +1000, Anthony Towns wrote:
> 'common': everything that might reasonably appear in an "ff the
> shelf" install (ie, the contents of all task- packages)
I think that not all task- packages would be "common". There are bound
to be some speciali
> > On 04-Oct-00, 14:27 (CDT), Anthony Towns wrote:
> > > So I wonder if changing it to something more like:
> > > 'important': things that will be on *every* system, except *very*
> > > specialised ones
> > > 'standard': everything that might reasonably appear in an "off the
> > >
On Mon, Oct 09, 2000 at 12:13:47PM -0500, Steve Greenland wrote:
> On 04-Oct-00, 14:27 (CDT), Anthony Towns wrote:
> > So I wonder if changing it to something more like:
> > 'important': things that will be on *every* system, except *very*
> > specialised ones
> > 'standard':
On 04-Oct-00, 14:27 (CDT), Anthony Towns wrote:
> So I wonder if changing it to something more like:
>
> 'important': things that will be on *every* system, except *very*
> specialised ones
> 'standard': everything that might reasonably appear in an "off the
>
On Thu, 5 Oct 2000 at 02:11, Branden Robinson wrote about "Re: Priorities":
> Because Ian Jackson, who originally authored that language, likes TeX and
> Emacs, but hates X. Our present definition of "standard" has everything to
> do with his personal preferences.
On Thu, Oct 05, 2000 at 05:27:21AM +1000, Anthony Towns wrote:
> I know a lot of people are annoyed by tetex and emacs being standard
> priority, and I personally find it odd that X isn't "standard" these
> days, especially since it's "more of a piece of infrastructure than an
> application".
Beca
Santiago Vila <[EMAIL PROTECTED]> wrote:
> Also, packages in the base system (i.e. those in base2_1.tgz)
> should not require a package outside of the base system to work, because
> otherwise the base system would be "broken". Whether this "requires"
> is just Depends or both Depends and Recommend
On Sat, 28 Nov 1998, Wichert Akkerman wrote:
> A while ago someone (Santiago iirc) filed a bugreport about packages
> depending on other packages with a lower priority. This made me
> wonder about allowed relations between packages. Reading the policy
> document does not give any explicit demands.
45 matches
Mail list logo
