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: ] 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. It's not remotely difficult to put the overrides in the dinstall database where they can only be modified by ftpmaster, or to have the dinstall cronjob update from boot-floppies CVS, or to extract them automatically from individual task.debs direct from the pool. I still think boot-floppies CVS would be the best compromise between ease of access (since all developers have access to it, all maintainers pretty much do too...) and ease of implementation (cvs checkouts are pretty straightforward to automate). But hey, easier to jump off the deep end than try working out the best solution or building consensus, right? Now that www.d.o is back up, I'll again cite the URL for the discussion we had about this: http://lists.debian.org/debian-devel-0008/msg00700.html. Some others of note: http://lists.debian.org/debian-devel-0008/msg00711.html http://lists.debian.org/debian-devel-0008/msg00700.html See particularly the last three paragraphs of that last one. > 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. Except they don't. Recommends is (quite reasonably) treated exactly the same as Depends by dselect, and even missing suggests are complained about ocassionally. If I've suggested anything specific at all, btw, it wasn't anything in their control file, but rather an extra file in /usr/share/doc or similar. *shrug* > > > * 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 ... Yeah, because those maintainers care a whole lot more about whether something's inelegant rather than whether or not it works. Better to not let people manage tasks at all than to do *that*. > > > 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 Let me spell it out for you then: there is nothing concrete about unwritten code. If you'd wanted to get this fixed in your own special way, you've had nine months to work out what you want. You've had nine months to reconsider your agreement to the "Task:" idea. You've had nine months to go out and implement something. But you didn't, so eventually I went out and did what we'd discussed on -devel nine months ago. And now, of course, you've decided that it offends your sense of aesthetics, and therefore must absolutely *never* happen, and that I'm a completely unreasonable little bigot for daring to propose such a thing. Am I misreading something here? Is there something that tasks are currently useful for that a combination of "Task:" fields and non task metapackages doesn't work for? If so, there's a real problem with this solution that needs to be fixed, and you're welcome to ignore any and all insinuations so we can get on with that. If not, though, are you seriously exaggerating a difference in taste and perhaps some wishlists that no one's been bothered enough to try implementing to the whole proposal being based on (how did it go again?) "a horrid assumption, [that] says bad things about either the state of Debian or the assumptee." ? Additionally, it's note like if we later decide `Task:' fields suck, that we can't just later rip them out and pretend they never existed. It's not even like it'd be a great deal of effort. Cheers, aj -- Anthony Towns <aj@humbug.org.au> <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)
Attachment:
pgpUzAgA9dKXW.pgp
Description: PGP signature