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 w
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
> > 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 ha
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 fe
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
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 t
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'
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.
> Certain
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 spe
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
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
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 se
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 car
On Tue, May 08, 2001 at 12:19:20PM -0400, Sam Hartman wrote:
> > "Anthony" == Anthony Towns 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 discussion
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
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 m
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 depe
> "Anthony" == Anthony Towns 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 reasonable
y can run tasksel.
If the "set of software" is just a logical grouping 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
On Tue, May 08, 2001 at 09:55:48AM -0400, Sam Hartman wrote:
> > "Anthony" == Anthony Towns 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 dselect.
> "Anthony" == Anthony Towns 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 frontend-speci
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
> installi
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 M
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 pre
> "Anthony" == Anthony Towns 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
Anthony> wr
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 parti
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 numb
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
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 ta
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 d
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
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 everyth
34 matches
Mail list logo
