Re: Tasks policy
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 Mon, May 07, 2001 at 07:32:10PM -0400, Sam Hartman 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-specific fields being mandated by policy and don'tt see a need for tasksel to be a distinguished frontend. I understand why apt-get might not want to support or reverse-recommends, but I think that the actual frontends should support this. 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. It's unlikely dpkg or apt-get will handle tasks directly ever, but perhaps some of the frontends (deity or dselect) will eventually. If you want to hack on this at some point, that's fine, but getting tasks to work for their primary goal is much more important right now. 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 were called Reverse-Recommends, since such a thing is useful for other purposes too. 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 specifications just isn't warranted. It's quite reasonable, for example, to try to setup a mail server (with SMTP and POP and IMAP and maybe even a webmail application, say) and then decide you'd like to replace exim with postfix, eg. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpHR5WaG1cXE.pgp Description: PGP signature
Re: Tasks policy
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 and removing tasks elegantly yet. It's unlikely dpkg or apt-get will handle tasks directly ever, but perhaps some of the frontends (deity or dselect) will eventually. If you want to hack on this at some point, that's fine, but getting tasks to work for their primary goal is much more important right now. Totally agreed and understood! My thought was simply that it would be easier for people to make sense of if they could just look at the control file of one package (task-foo) rather than searching through the control files of all packages. But again, you have working code, so the point is somewhat moot. 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 specifications just isn't warranted. It's quite reasonable, for example, to try to setup a mail server (with SMTP and POP and IMAP and maybe even a webmail application, say) and then decide you'd like to replace exim with postfix, eg. Sort of agreed, which was why I said that it must have a different set of rules. Remember that the Task: header will be under the control of a strictly limited number of packages. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Defaults for satisfying dependencies - ordering gone?
Hi, The section: sectheadingDefaults for satisfying dependencies - ordering /heading in particular the paragraph: p Therefore a dependency on a virtual package should contain a concrete package name as the first alternative, so that this is the default. /p seems to be missing from policy (it existed in the packaging manual). Is this intentional? The only similar paragraph I can find is: If you want to specify which of a set of real packages should be the default to satisfy a particular dependency on a virtual package, you should list the real package as an alternative before the virtual. but needless to say, this doesn't have the same effect. Thanks, -- Marcelo | No matter how fast light travels it finds the darkness [EMAIL PROTECTED] | has always got there first, and is waiting for it. | -- (Terry Pratchett, Reaper Man)
Re: Tasks policy
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 frontend-specific fields being mandated by policy and don'tt see a need for tasksel to be a distinguished frontend. I understand why apt-get might not want to support or reverse-recommends, but I think that the actual frontends should support this. 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. 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. I know many Debian users who expect to be able to do apt-get install task-blah long after the initial install. While I was not involved as a developer at the time this discussion happened the last time, I saw a major advantage of tasks over profiles that I could install new tasks as I found I needed them rather than having to reinstall a system and select a new profile. We will never fully be able to support the users who have grown used to being able to apt-get install tasks; you have convinced me of that. However policy's primary purpose seems to be to document existing practice and I don't think that we are doing that very well by dropping support for the existing practice of usefully adding tasks after the initial install. Yet I understand we have finite time. Would it be reasonable to get tasksel install task-name added as a command line invocation for people to use in scripts and to have the policy text say that frontends that handle recommends should handle tasks? I'm not particularly concerned about the specifics of the text, but I believe we must allow people an option to continue to use tasks in interactive scripts and we should encourage people to support it appropriately. --Sam
Re: Tasks policy
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 dselect. 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 to get tasksel install task-name added as a command line invocation for people to use in scripts I'm not sure what scripts have to do with anything, but adding a command line option is entirely trivial. You check the code out from CVS, or do an apt-get source, you write the code, and you send it to Randolph. It doesn't need discussion here. and to have the policy text say that frontends that handle recommends should handle tasks? Not really. Frontends should do whatever their authors deem appropriate and have time to implement. If you want to send in patches, or write your own frontend, more power to you. It's not policy's place to say anything about what features you should and shouldn't implement though. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpQD2ibmsxt0.pgp Description: PGP signature
Re: Tasks policy
On 08-May-01, 08:55 (CDT), Sam Hartman [EMAIL PROTECTED] 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 dselect. 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. If the set of software is a task, then they 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 (and explain why they are not tasks. Something like appending -group (e.g. emacs-group, roxen-group), so that one can do apt-cache search '-group' to find all those meta packages. -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Tasks policy
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 reasonable to get tasksel install task-name added as a command line invocation for people to use in scripts Anthony I'm not sure what scripts have to do with anything, but Anthony adding a command line option is entirely trivial. So, it is very annoying to write a script to go into tasksel, move to the appropriate task, select it and go down to OK. If I want to install a task as part of some management script, I really do need a command line for it. 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 here. I resent the implication that I'm responsible for fixing any problem that I discover. I believe there is value in pointing out a problem report even if you don't have the resources to fix it. I believe that your proposal will break people who are installing tasks after initial install. I believe this is sufficiently common that we don't want to break this usage pattern. Either I'm right and we as a policy group have an obligation to make sure that we implement the change in a manner that does not break our users--this obligation existing regardless of whether I'm willing to go off and write code on this particular issue, or I'm wrong and I'm simply asking for a feature request. I'm sorry I don't have a good way to give you evidence on how common the usage pattern of installing tasks after initial install is. I've considered ways of getting this info, and the best thing I've found so far is asking users. and to have the policy text say that frontends that handle recommends should handle tasks? =20 Anthony Not really. Frontends should do whatever their authors Anthony deem appropriate and have time to implement. If you want Anthony to send in patches, or write your own frontend, more Anthony power to you. It's not policy's place to say anything Anthony about what features you should and shouldn't implement Anthony though. I disagree in general; there are cases where interoperability requires us to recommend or even require features be implemented. However, I agree that would be going to far. I believe that by describing parts of a protocol like the format of the packages file entry you are implicitly saing that users of that protocol should implement the parts of that protocol that are appropriate for their application. I think a footnote indicating that we are changing from a model where tasks depend on a lot of stuff to one where they reverse-recommend means that some users may still expect to be get useful results by installing a task package.
Re: Tasks policy
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 support to apt (a Task: field is really a reverse dependancy, if you get what I mean). Reverse dependancies have other uses, and the lower in the package manager stack they are supported, the better. -- see shy jo, cringing at the concept of a package manager stack, but that's what we have now
Re: Tasks policy
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 point of Task: fields being in the package is so that packages can be removed from the archive without breaking any tasks they might be a part of. I recently sent a mail questioning the Task: field. Seems I have misunderstood (I thought it was intended to be a field in task packages, listing the packages in the task). Now that I understand, I support Aj's proposal wholeheartedly, except my thoughts about using sections to organize tasks, rather than overloding the package name, still stand. -- see shy jo
Re: Tasks policy
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 released, I think consensus
was that we should use override files to populate these fields, rather
than letting maintainers add their own packages directly to tasks. I'm
not sure if we came to a consensus about how these override files would
be maintained though (or who by: ftpmaster? -boot? the individual task-*
maintainers?). It's probably best to put it in boot-floppies CVS, and have
dinstall use that.
I don't recall a discussion of or decision on using overrides files.
While it seems that letting developers create task packages willy-nilly
with no rules or supervision has been a disaster, the overall quality of
the dependnaices in individual tasks is ok, so I see no need to have
centralized control over that. Bug reports suffice. So no need for overrides
files.
I also don't understand why this new Task: header is being introduced. I
mean, I understand why you don't want to use dependancies. But why not
let tasks use Recommends and Suggests in a sensible fashion, and simply
make tasksel install all packages listed in either field by a task package?
This would make tasks usable in eg, dselect and any other decent apt
frontend, and it wouldn't add a new, seemingly hackish field.
* tasks should be priority optional (and thus packages in
tasks should be priority optional),
I think you mean the packages in a task should be option or higher (not
extra), right?
* tasks should follow a naming convention so they can be organised
better by tasksel. Probably:
task-devel-{c,c++,objc,haskell,...}
task-lang-{german,french,japanese,chinese,...}
task-server-{web,news,mail,database,dns,...}
task-user-{desktop,office,games,junior,...}
task-hware-{dialup,printer,laptop,...}
Well we could let tasksel use the Section field, or some new field instead
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
Or even (why overload package the field at all) --
Package: desktop
Task: yes
Tasksel-Section: user
Package: web-server
Task: yes
Tasksel-Section: servers
Or even this (the only problem with it is that our current set of
sections is so limited and hard to change) --
Package: desktop
Task: yes
Section: user
Package: web-server
Task: yes
Section: servers
* we should have tasks specifically for emacs and tetex (even though
both could be replaced by a wordprocessor in task-office, say).
possibly:
task-sware-{tetex,emacs}
and require any additional tasks like this get run through policy
first. If nothing else, historical reasons are a good argument
for tetex and emacs, and are obviously immune to slipper
slopes. :)
It's worth noting that for a good 3 or 4 months after potato's release,
new installs that used tasksel did not get emacs or tex, or anything
else in standard, and that although people eventually complained about
other packages in standard not being installed, I never saw a single
complaint that those two were missing. After all, it didn't affect
upgrades, and I guess people who wanted emacs had no problem with using
apt afterwards.
--
see shy jo
Re: Tasks policy
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 discussion here.
I resent the implication that I'm responsible for fixing any problem
that I discover.
Eh?
Seriously, it's quite easy. That's how Task: got implemented. I ran
apt-get source, read the code 'til I understood it, implemented it,
did some testing, sent the patch to Randolph, and it got into the archive.
I believe there is value in pointing out a problem
report even if you don't have the resources to fix it.
What do you mean you don't have the resources to fix it? The code's all
right there. There're debuggers, and compilers and everything. There's
no licensing restrictions in your way. There's not even any controversy
about whether it'd be a Good Thing. It's not even hard.
(If you're trying to say you don't have the skill to fix it, then, quite
frankly, you probably shouldn't be trying to insist on what others should
be doing.)
Anthony Not really. Frontends should do whatever their authors
Anthony deem appropriate and have time to implement. If you want
Anthony to send in patches, or write your own frontend, more
Anthony power to you. It's not policy's place to say anything
Anthony about what features you should and shouldn't implement
Anthony though.
I disagree in general; [...]
That doesn't really surprise me. It's much more fun to disagree about
things than to fix them. Even when it's not actually easier.
For reference:
--- tasksel-1.1/tasksel.c Tue Apr 24 16:35:07 2001
+++ tasksel-1.2aj/tasksel.c Wed May 9 02:56:26 2001
@@ -176,6 +176,21 @@
}
tasklist = tasks_enumerate(tasks);
+ if (noninteractive) {
+for (;optind argc; optind++) {
+ /* mark task argv[optind] for install, if it exists */
+ int i;
+ for (i = 0; i tasks.count; i++) {
+if (strcmp(tasklist[i]-name, argv[optind]) == 0) break;
+ }
+ if (i == tasks.count) {
+printf(E: %s: no such task\n, argv[optind]);
+ } else {
+tasklist[i]-selected = 1;
+ }
+}
+ }
+
if (r == 0) {
r = doinstall(tasklist, tasks.count,
pkglist, (installreqd || installimp || installstd
Getting a nice command line, rather than just the simplest to implement
is left as an exercise to the interested reader.
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. GPG signed mail preferred.
``_Any_ increase in interface difficulty, in exchange for a benefit you
do not understand, cannot perceive, or don't care about, is too much.''
-- John S. Novak, III (The Humblest Man on the Net)
pgpilQ6y7A3Eg.pgp
Description: PGP signature
Re: Tasks policy
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 of.
Unfortunately www.debian.org seems to be down, so I can't cite a url for
the discussion from a while ago, but the summary is basically that during
the freeze (ie, when I start removing packages left right and centre),
it's very easy for a task to get broken if task-membership is specified
as part of the task. If, instead, it's specified as part of the package
that's in the task, once the package is removed, the fact that it was
meant to be in the task disappears too, and fewer things break.
On the other hand, the way tasks currently work, with a single person
choosing which packages go in a task works fairly well (as you've said),
so that's something worth preserving. The way we can preserve that is
with override files.
I also don't understand why this new Task: header is being introduced.
I'd encourage you to reread the thread from last year. I posted a URL
earlier in the thread.
* tasks should be priority optional (and thus packages in
tasks should be priority optional),
I think you mean the packages in a task should be option or higher (not
extra), right?
Well, whatever. If they're standard or higher, they'll be installed
anyway, so it doesn't much matter. But yeah, that's all I was getting at.
It also brings into play the don't Conflict: with other things rules
from elsewhere.
* tasks should follow a naming convention so they can be organised
better by tasksel. Probably:
task-devel-{c,c++,objc,haskell,...}
task-lang-{german,french,japanese,chinese,...}
task-server-{web,news,mail,database,dns,...}
task-user-{desktop,office,games,junior,...}
task-hware-{dialup,printer,laptop,...}
Well we could let tasksel use the Section field, or some new field instead
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 tasks. We could
have more than one, and make it:
Package: task-desktop
Section: user-tasks
Package: task-web-server
Section: server-tasks
Or even (why overload package the field at all) --
...because we're already doing it, and because it helps separate tasks
in existing UIs.
Or even this (the only problem with it is that our current set of
sections is so limited and hard to change) --
Sections are adminned by overrides by ftpmaster. There just needs a
good reason to create a new one (well, and some patience), it's not
really difficult.
It's worth noting that for a good 3 or 4 months after potato's release,
new installs that used tasksel did not get emacs or tex, or anything
else in standard,
(Note that everyone who wanted TeX probably chose task-tex anyway)
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. GPG signed mail preferred.
``_Any_ increase in interface difficulty, in exchange for a benefit you
do not understand, cannot perceive, or don't care about, is too much.''
-- John S. Novak, III (The Humblest Man on the Net)
pgpGrjP96SYSP.pgp
Description: PGP signature
Re: Tasks policy
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 tasks. We could have more than one, and make it: Package: task-desktop Section: user-tasks Package: task-web-server Section: server-tasks I would prefer something like this. It's worth noting that for a good 3 or 4 months after potato's release, new installs that used tasksel did not get emacs or tex, or anything else in standard, (Note that everyone who wanted TeX probably chose task-tex anyway) Well, ok, but nobody complained about a missing task-emacs anyway. -- see shy jo
Re: Tasks policy
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 it's a problem if the way we reimplement tasks is not something other tools can eventually handle elegantly. I don't want to see tasks be something hackish that is bolted onto the side of Debian, I want to see them cleanly integrated and supported by as many tools as possible. 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 specifications just isn't warranted. Have you thought at all about renaming Task: to Enhances:? Dpkg already has some limited Enhances support, the two fields really have very close if not identical meanings, and perhaps other dpkg frontends will one day support Enchances, giving us task support for free. (I would really like to be able to continue to use tasks in dselect, even though this is not thier primary purpose. Dselect is still an alternate installation path that you can choose instead of tasksel.) If tasksel just starts looking at Enhances fields for tasks, we can simply make the policy say that you cannot add a Enhances: task-* to a package without asking the relevant authority. -- see shy jo
Re: Finishing the FHS transition
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 for release, and we shall not tweak informative fields in an attempt to indirectly determine what goes into a release independent of actual performance and conformance to the normative aspects of the policy document. manoj -- You will be dead within a year. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Tasks policy
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 still allow recommends/suggests like relations to point into non-free. Task-membership headers should ultimately have a different meaning and different operation from Enhances. BTW, I don't see enhances in the dpkg 1.9.4 changelog.. Jason
Re: Tasks policy
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 specifications just isn't warranted. Have you thought at all about renaming Task: to Enhances:? 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. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgp4m2V1tB67T.pgp Description: PGP signature
Re: Tasks policy
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 don't mean overrides files that ftpmaster takes care of. If it is possible to do it without override files then that should be the prefered solution. Otherwise getting the Task: information reliably into the status file will be very hard and I think having task information there will be very important in future. Jason
Bug#53582: PROPOSAL] base section: let's get rid of this one at last
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
Re: Tasks policy
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 here, and I make package blah better! The political details which lead to its implementation are of no consequence, just as whatever details lead to the implementation of Suggests are of no consqeuence -- we have the field, it has a clearly defined meaning, go use it as you will or as policy dictates. Task-membership headers should ultimately have a different meaning and different operation from Enhances. I don't see it. -- see shy jo
Re: Tasks policy
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 complexity of dependency specifications just isn't warranted. Have you thought at all about renaming Task: to Enhances:? 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. If we're intending to use a small number of tasks, then that should not be a big deal, since new task creation would be rare. Also, it's surely possible to make whatever Packages file creation overrides mechanism is developed just _add_ the task packages to existing Enhances fields, preserving whatever else might be there. -- see shy jo
Re: Tasks policy
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 some cvs repository somewhere[1]. * Eliminate all usefulness of tasks except when manipulated by one single special purpose tool (tasksel). (This includes making it impossible to install a task and receive bugfix upgrades to it later.) But the only real differences between this proposed system and the system Bruce wrote hurredly over Xmas for hamm or so are: * In this system, we have these useless task-* packages cluttering up tools that cannot use them, while in Bruce's system, the tasks were hidden out of the way. * Maintainers of task packages do get to provide a description of the task. In AJ's system, that's really all maintaining a task package means -- you maintain a package description, and nothing more. * In Bruce's system, the task selector self-destructed and was not callable after install. AJ asked for a concrete counterpropsal, and this is mine: If you really want to do this, just go back to Bruce's system. Redo it so it's not so blasted ugly and confusing, fix the self-destructive aspect, but use the same idea. Which likely means just hardcoding the tasks and what packages comprise them in tasksel, and when a task is selected, have apt install all available packages that are in the task. If we need a quick fix for the task problem in time for the freeze, this is it. sigh -- see shy jo [1] The more I think about it, the more the reasons for this incense me. All this talk of overrides files has the unstated assumption that we cannot simply file bugs on packages, and get their maintainers to add the appropriate Task: or Enhances: or whatever fields. This is a horrid assumption, and it says bad things about either the state of Debian or the assumptee.
Re: Tasks policy
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 non-developers have commit access to? Or moving them into the task package themselves, but not in the control record? Or shall we just forget I suggested that originally. Yes, clearly it's a power trip and I don't trust anyone else. Why, I'm evil and thoughtless and just plain baaad. * Eliminate all usefulness of tasks except when manipulated by one single special purpose tool (tasksel). (This includes making it impossible to install a task and receive bugfix upgrades to it later.) Yeah, because hey, if the tools aren't written now (or at the very least mandated by policy) it'll be impossible to ever write them in future. AJ asked for a concrete counterpropsal, and this is mine: If you really want to do this, just go back to Bruce's system. Redo it so it's not so blasted ugly and confusing, fix the self-destructive aspect, but use the same idea. Which likely means just hardcoding the tasks and what packages comprise them in tasksel, and when a task is selected, have apt install all available packages that are in the task. Forget all the code that exists and is working right now, and rewrite it based on this old code that everyone's forgotten. Feh. Cheers, aj, getting fed up with trying to help -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpQ6FBKcMoaF.pgp Description: PGP signature
Re: Tasks policy
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 their package be on the fast track to user installation. If a maintainer doesn't want that, or is too busy or MIA to deal with it, do we really want their package being installed by thousands of newbies? -- see shy jo
Re: Tasks policy
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 again have perfectly good general purpose fields, Suggests and Recommends, that already do the same thing. * Eliminate all usefulness of tasks except when manipulated by one single special purpose tool (tasksel). (This includes making it impossible to install a task and receive bugfix upgrades to it later.) Yeah, because hey, if the tools aren't written now (or at the very least mandated by policy) it'll be impossible to ever write them in future. I think it very unlikely that we will ever get support for some hackish field only used by task packages into Dselect, and Dpkg, and Apt, and Aptitude, and Deity, and Red Carpet and ... This is why I have been trying to generalize the thing all along. A more general purpose field will be more generally used, and so people will have more incentive to implement it. Plus, it probably solves some other problems out side of task space. AJ asked for a concrete counterpropsal, and this is mine: If you really want to do this, just go back to Bruce's system. Redo it so it's not so blasted ugly and confusing, fix the self-destructive aspect, but use the same idea. Which likely means just hardcoding the tasks and what packages comprise them in tasksel, and when a task is selected, have apt install all available packages that are in the task. Forget all the code that exists and is working right now, and rewrite it based on this old code that everyone's forgotten. Bruce's stuff was not so bad. Aside from being a rushed implementation, the idea was pretty good. -- see shy jo, ignoring certian nuances
