On Mon, Aug 14, 2000 at 10:12:38PM -0700, Joey Hess wrote: > The problem, as I see it, is that task packages declare a strong > dependency where often none really exists. After all, if it were a real > dependancy, we'd not be having this discussion, since aj/james/whoever's > course of action then would have been a lot more clear: remove both > packages, or fix one. Thus, it still seems to me that allowing that to > be weakened to a reccommends would be the ideal solution.
What I'd like to happen is basically be able to remove the package,
and just have the task automatically act as though that package had
never existed. Not complain in dselect about it, not worry people when
Apt gives you a warning, not do anything.
One way of doing this would be to include the information in the package's
entry in the Packages file, a la:
Package: foo
Version: 2.71828
Depends: libc6
Task: metasyntactical-packages
If the package is removed from the distribution, it's implicitly no longer
in the task.
The problem with doing it this way, is you can't easily make a
"aj-favourites" task separate from the distribution that includes things
from the distribution. The only way around this I can think of is to
make a task-aj-favourites package that has a Task: aj-favourites field
and Depends: on the packages from the appropriate distribution. This may
be inelegant. It's not a problem within Debian, though (but the current
way of doing things is).
Another way of doing might be to generate task packages as we have now
as part of dinstall, and install them into the archive. Another way
would be to not do this as part of dinstall, but on an autobuilder. This
wouldn't be as effective if there's a security update that needs to get
out immediately though.
> Compare with task-games. I have put a *lot* of thought into what goes into
> that package. If it did not have one single maintainer, with a coherent
> vision, it would be a random set of games, probably eventually growing
> to include a large portion of the games in debian. Which would defeat
> its purpose.
How we make this available to apt, or frontends doesn't have to influence
how we actually maintain it. Consider, for example:
#!/usr/bin/perl -w
my %pkgtasks = (); # $pkgtasks{"netbase"} = [ "networking" ]; eg
while(<STDIN>) {
chomp;
next unless m/^(\S+)\s+(\S+)$/; # <task> <package>
push @{$pkgtasks{$2}}, $1;
}
while(<>) {
chomp;
if (m/^Package: (\S+)$/) {
my $cpkg = $1;
print "Package: $cpkg\n";
print "Task: " . join(", ", @{$pkgtasks{$cpkg}}) . "\n"
if (defined $pkgtasks{$cpkg});
} elsif (m/^Task:.*$/) {
# discard
} else {
print "$_\n";
}
}
Used to add Task: fields to a Packages file, something like:
$ cat tasks
networking netbase
metasyntactical-packages foo
$ ./add-task /var/lib/dpkg/available < tasks | less
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
pgpIkFGeB6zoQ.pgp
Description: PGP signature
