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 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
Hi,
The section:
Defaults for satisfying dependencies - ordering
in particular the paragraph:
Therefore a dependency on a virtual package should contain a
concrete package name as the first alternative, so that this
is the default.
> "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 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.
On 08-May-01, 08:55 (CDT), Sam Hartman <[EMAIL PROTECTED]> 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 ds
> "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
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 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:
> 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 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
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
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
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
On Tue, 8 May 2001, Marcelo E. Magallon wrote:
> seems to be missing from policy (it existed in the packaging manual).
> Is this intentional? The only similar paragraph I can find is:
APT 5 has recently begun using the highest priority (or installed) package
that satisfies the provides for ca
>>"Seth" == Seth Arnold <[EMAIL PROTECTED]> writes:
Seth> Is this working under the assumption that the release manager will drop
Seth> all packages "not recent enough" when freezing?
The assumption is that the release manager shall come up with
whatever criteria seem reasonable to him
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 spe
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
Julian Gilbey wrote:
> Yann Dirson wrote:
> I agree with Yann's suggestion. Joey, are you agreeable to this
> change; Yann, are you seconding this proposal? If so, it'll go in a
> soon-to-be-released policy version.
Fine with me.
--
see shy jo
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'
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
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 fe
> > 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
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
26 matches
Mail list logo
