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
having
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 wade through
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. Would it be
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 dependancy
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 potato
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
Anthony need
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 care
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.
Certainly, I
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
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 few
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 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 was:
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 so we
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 do
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
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.
You
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 go to
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
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 particular,
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 Eichin
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 prefer it
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
(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
23 matches
Mail list logo
