On Tue, May 08, 2001 at 11:04:34PM -0400, Joey Hess wrote:
> Anthony Towns wrote:
> > Or moving them into the task package themselves, but not in the control
> > record? Or shall we just forget I suggested that originally.
> Well, I had.
Well, it's possible I wasn't explicit enough. What I said
Anthony Towns wrote:
> Or moving them into the task package themselves, but not in the control
> record? Or shall we just forget I suggested that originally.
Well, I had.
That's a reasonable alternative. Oh, except, I seem to remember you wanted
to use some special-purpose field for it, when we
On Tue, May 08, 2001 at 10:34:26PM -0400, Joey Hess wrote:
> * Move control of what packages a task includes out of the hands of the
> creator of the task, and into the hands of people who have commits to
> some cvs repository somewhere[1].
Like boot-floppies CVS which every developer and a f
It occurs to me that what AJ's trying to do and its results can perhaps be
restated as follows (with apologies to AJ -- you have the best of
intentions):
* Move control of what packages a task includes out of the hands of the
creator of the task, and into the hands of people who have commits to
On Wed, 9 May 2001, Anthony Towns wrote:
> On Mon, May 07, 2001 at 04:05:14PM -0400, Joey Hess wrote:
> > I don't recall a discussion of or decision on using overrides files.
>
> Well, uh, you were in it...
>
> "Overrides files" may not be quite the most accurate way of expressing it.
> Certai
Anthony Towns wrote:
> > of re-overloading the package name. I think all those names are very, very
> > ugly. Wouldn't this be nicer --
> > Package: task-desktop
> > Tasksel-Section: user
> > Package: task-web-server
> > Tasksel-Section: servers
>
> Well, I mentioned somewhere having a separate s
On Mon, May 07, 2001 at 04:05:14PM -0400, Joey Hess wrote:
> I don't recall a discussion of or decision on using overrides files.
Well, uh, you were in it...
"Overrides files" may not be quite the most accurate way of expressing it.
Certainly, I don't mean overrides files that ftpmaster takes ca
On Tue, May 08, 2001 at 12:19:20PM -0400, Sam Hartman wrote:
> > "Anthony" == Anthony Towns <[EMAIL PROTECTED]> writes:
> Anthony> You
> Anthony> check the code out from CVS, or do an apt-get source, you
> Anthony> write the code, and you send it to Randolph. It doesn't
> Antho
Anthony Towns wrote:
> So, here's the deal. We need to get a proper policy for tasks fairly soon.
Amen.
> tasksel in sid supports a "Task:" header for packages so we can be a
> little more flexible than having every task- depend on everythig in it.
> This was discussed on -devel just after potat
Anthony Towns wrote:
> > Would it not be much easier for the task packages _themselves_ to
> > contain Task: fields, instead of the individual packages, which would
> > function like weak Recommends: fields:
>
> Not really. The code's already written to do things the other way around,
> and the
Anthony Towns wrote:
> You can always run tasksel, select the task, and go "Ok", instead of using
> "apt-get install ..." though. Making "tasksel install server-dns" just go
> ahead and install the task, bypassing the UI, would be fairly simple too.
Another option would be to add real reverse dep
> "Anthony" == Anthony Towns <[EMAIL PROTECTED]> writes:
>> Yes, that was the original point of tasks. However, tasks are
>> also used today by people who want to get a set of software
>> installed after the initial install. [...]
>> Yet I understand we have finite time. Wo
On Tue, May 08, 2001 at 09:55:48AM -0400, Sam Hartman wrote:
> > "Anthony" == Anthony Towns <[EMAIL PROTECTED]> writes:
> Anthony> Remember: the point of tasks is to make the initial
> Anthony> install simpler, so that people can get started on Debian
> Anthony> without having to w
> "Anthony" == Anthony Towns <[EMAIL PROTECTED]> writes:
Anthony> On Mon, May 07, 2001 at 07:32:10PM -0400, Sam Hartman
Anthony> wrote:
>> So, I think that support in tools besides tasksel is critical
>> to this policy proposal being useful. I don't like the idea of
>> h
On Tue, May 08, 2001 at 02:54:59PM +1000, Anthony Towns wrote:
> Remember: the point of tasks is to make the initial install simpler,
> so that people can get started on Debian without having to wade through
> dselect.
>
> So it's not a problem if *nothing* other than tasksel can handle
> install
Replying to a few messages at once.
On Mon, May 07, 2001 at 06:16:29PM +0100, Julian Gilbey wrote:
> My thought was that apt and dselect would be taught to recognise
> Tasks: as a new type of dependency header, similar to Depends,
> Recommends and Suggests, but with slightly different rules.
On
On Mon, May 07, 2001 at 04:23:47PM -0400, Joey Hess wrote:
> > My thought was that apt and dselect would be taught to recognise
> > Tasks: as a new type of dependency header, similar to Depends,
> > Recommends and Suggests, but with slightly different rules.
>
> If this were done, I would much pr
> "Anthony" == Anthony Towns <[EMAIL PROTECTED]> writes:
Anthony> --HG+GLK89HZ1zG0kk Content-Type: text/plain;
Anthony> charset=us-ascii Content-Disposition: inline
Anthony> Content-Transfer-Encoding: quoted-printable
Anthony> On Mon, May 07, 2001 at 11:42:49AM -0400, Mark Ei
Julian Gilbey wrote:
> On Mon, May 07, 2001 at 11:42:49AM -0400, Mark Eichin wrote:
> > err, does this break the use of tasks with apt-get later on? I've
> > found it very useful to do (for example) "apt-get install task-x-window-system"
> > after getting a machine otherwise working (in particula
On Sun, 06 May 2001, Anthony Towns wrote:
> So, here's the deal. We need to get a proper policy for tasks fairly soon.
I agree. The current task-* packages are mostly useless cruft for what they
were supposed to do, i.e. help users during the install.
> * There should only be a limited num
On Mon, May 07, 2001 at 11:42:49AM -0400, Mark Eichin wrote:
> err, does this break the use of tasks with apt-get later on? I've
> found it very useful to do (for example) "apt-get install task-x-window-system"
> after getting a machine otherwise working (in particular, that's the
> easy way to g
On Mon, May 07, 2001 at 11:42:49AM -0400, Mark Eichin wrote:
> err, does this break the use of tasks with apt-get later on? I've
> found it very useful to do (for example) "apt-get install task-x-window-system"
Possibly. task-x-window-system isn't really the greatest example of a task,
though.
err, does this break the use of tasks with apt-get later on? I've
found it very useful to do (for example) "apt-get install task-x-window-system"
after getting a machine otherwise working (in particular, that's the
easy way to go to xf4 - install 2.2, then point to testing, then
apt-get install t
On Mon, May 07, 2001 at 08:23:52PM +1000, Anthony Towns wrote:
> > Would it not be much easier for the task packages _themselves_ to
> > contain Task: fields, instead of the individual packages, which would
> > function like weak Recommends: fields:
>
> Not really. The code's already written to
On Mon, May 07, 2001 at 11:06:41AM +0100, Julian Gilbey wrote:
> On Sun, May 06, 2001 at 04:42:19PM +1000, Anthony Towns wrote:
> > (Cc'ed to debian-boot)
> > tasksel in sid supports a "Task:" header for packages so we can be a
> > little more flexible than having every task- depend on everythig i
On Sun, May 06, 2001 at 04:42:19PM +1000, Anthony Towns wrote:
> (Cc'ed to debian-boot)
>
> (First in porbably a series of policy changes needed for woody...)
>
> So, here's the deal. We need to get a proper policy for tasks fairly soon.
>
> tasksel in sid supports a "Task:" header for packages
(Cc'ed to debian-boot)
(First in porbably a series of policy changes needed for woody...)
So, here's the deal. We need to get a proper policy for tasks fairly soon.
tasksel in sid supports a "Task:" header for packages so we can be a
little more flexible than having every task- depend on everyt
27 matches
Mail list logo
