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:
pgpafobBnn5xW.pgp
Description: PGP signature