Re: Ignoring dependance on "important" packages?
On Sat, Jul 24, 1999 at 03:04:39PM -0400, Adam Di Carlo wrote:
> "Martin Bialasinski" <martin@internet-treff.uni-koeln.de> writes:
>
> > See? This extra semantic will do some good I believe. And if Debian
> > continues to grow that fast, such a thing is badly needed.
>
> No, I don't see and vehemently disagree.
Disclaimer: I came in late, so my apologies if this has been discussed
before, but I figure if it hasn't, then some of you might find it
interesting.
About task packages: I've always thought that the best way to do a task
package is _not_ with dependencies on all the various parts. This has
many drawbacks, the main one being that it's totally inflexible. For
me, a task package should be just like any other package, except that it
happens to install a script of some sort in /usr/lib/tasks or whereever
would be appropriate. We also define some sort of way to communicate
between this script and apt, or maybe we just have the script call apt-get
directly; whatever. This script when run then will do whatever it needs
to do to talk to the user and install the package. The best example I
can think of for this is X. Trying to figure out what needs to be installed
what with xserver-common, xserver-<your server here>, all the fonts (not
Required:, but necessary for just about everyone), xfree86-common,
xbase-clients, ... it's all very modular and nice, and allows you to do
all sorts of different configurations with pure X terminals and everything,
but trying to figure out which ones to install is fairly insane for a new
user, and it's easy to miss something that you need.
So the task-x package would provide a script that would ask the
user about their configuration, autoprobe to figure out what xserver-foo
package to install, and then get all the stuff that a person needs. A
task-x package like you seem to be discussing would just Depend: on all
the various basic x things that anyone might want, wouldn't install a
server, wouldn't work if you happened to be on a slightly different
configuration (if you had a font server available, say), and so on.
The same is true (though to a lesser extent) with the other task packages
I've seen mentioned -- I'm no sgml guru, but it seems that there are
many packages that, while very definitely part of basic sgml functionality,
are not needed by everyone (sgml->foo translators might fall into this
category).
This is just a general concept, which of course would need much more
refining, but I think that it has some merit. What do you think?
Again, I did just arrive, so if this has been discussed before or if I'm
suffering under some misconceptions about what you're talking about,
then my apologies for wasting your time and bits.
-- Nathaniel
Reply to: