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:
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 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
installing
Anthony == Anthony Towns aj@azure.humbug.org.au 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 aj@azure.humbug.org.au 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
of related packages
(emacs, say, or the roxen stuff) then a simple meta package can do the
job. Perhaps part of the tasks policy proposal should be to specify
an alternative mechanism/naming standard for such groupings (and
explain why they are not tasks. Something like appending -group
(e.g. emacs-group
Anthony == Anthony Towns aj@azure.humbug.org.au 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:
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 main
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 aj@azure.humbug.org.au 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
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 section for
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
installing and removing tasks elegantly yet.
Sure, but
On Tue, 8 May 2001, Joey Hess wrote:
Have you thought at all about renaming Task: to Enhances:? Dpkg already
has some limited Enhances support, the two fields really have very close
I would prefer if Enhances remained with it's original purpose: to
maintain the idelogical purity of main but
On Tue, May 08, 2001 at 03:24:33PM -0400, Joey Hess wrote:
Anthony Towns wrote:
Task: headers are more akin to Section: headers than Recommends:. Both in
that people really ought to be able to just uninstall a package if they
don't like it, and in that the complexity of dependency
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
Jason Gunthorpe wrote:
I would prefer if Enhances remained with it's original purpose: to
maintain the idelogical purity of main but still allow recommends/suggests
like relations to point into non-free.
Eh? Enchances purpose is to say hey, even though package blah doesn't
know about me, I'm
Anthony Towns wrote:
On Tue, May 08, 2001 at 03:24:33PM -0400, Joey Hess wrote:
Anthony Towns wrote:
Task: headers are more akin to Section: headers than Recommends:. Both in
that people really ought to be able to just uninstall a package if they
don't like it, and in that the
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 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
Using a dependency field for this would mean you couldn't create a new task
without NMUing every package you intend to put in that task.
Or we could, *gasp*, _ask_ the maintainers to add the task to their
packages Enhances field. Most maintainers will probably jump at the
opportunity to have
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 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 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 in it.
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.
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 aj@azure.humbug.org.au 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
(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
33 matches
Mail list logo