Re: Potato now stable
On Mon, 14 Aug 2000, Joey Hess wrote:
> Jason Gunthorpe wrote:
> > Tasks are bettered handled through some kind of non-package means. I've
> > long said we need to determine some kind of meta-package scheme (a
> > 'package' whose only purpose is to logically group other packages).
>
> How is introducing some basterdized form of package (perhaps it's just
> an entry in the Packages file or something), going to allow us to
> address problems like aj was talking about, where one of the things it
> depends on is removed from debian, and it needs to be updated?
You already have a bastadized form of packages, thats what a task package
is! The reason there are problems is specificly because task-packages
*aren't really packages* and we don't have enough expressiveness in our
packaging system to make them really work in a good way. [nor should we,
IMHO]
Trying to put hack upon hack into the package tools to support
magic-special packages in a limited fashion does not seem to be a good
solution because:
1) They are not packages!
2) You will never get everything you want because you are treating
specialized data in a generic way
The exact problem AJ is talking about is easially handled when you no
longer have task packages because suddenly there are no more dependencies,
you have a grouping which can be as strong or weak as the user+packager
desires.
Your suggestion would work to solve AJ's problem, but it suddenly makes
apt-get act really damn weird. You now have a black list of packages which
are hidden from recommends. This black list can't be updated if someone
uses dpkg because it doesn't know about it, and there is not really a
super-good way to edit it and it doesn't buy you anything in terms of ease
of use and organization.
I suspect the model APT guis, and perhaps apt-get too, will use for
recommends will be a white list where specific packages have their
recommends and suggests promoted to depends under user control. That list
can be fully maintained safely within APT and matches the familiar model
that dselect uses. (pull stuff in, don't exclude stuff out)
We also already have the concept of groups (priority/section), our users
are familiar with it - we even have automatic groups ala task-packages
(priority=important). So why not enhance that and create something
really spanky?
> > priorities of packages (ie -python doesn't need to install every freaking
> > package, but some are definately critical) and the ability to track and
> > optionally install new packages added to the group, remove the whole
> > group, etc.
>
> I don't disagree that all this would be nice, but it seems like icing on
> a cake that's just hiding the nasty holes.
Eh? That's completely unreasonable - the entire point is that expressing
groupings using the dependency mechanism has severe drawbacks, you have to
get away from that - you can't consider anything else as full of holes and
expect to fix any of the drawbacks!
> > Logically, the way to represent this is to have package declare their
> > membership in a grouping.
>
> You know, we had this discussion already. Please see the list archives
> of this winter. We decided this was not the correct way to do it,
I'm well aware of that - and that has zippo to do with delivery of the
data. We already have the ability to override sections and priority,
groups are not a big streatch.
Inling group membership with each package is a good way to deliver this
data without making major changes to the delivery system, another option
is to throw another index file in the archive or somehow abuse the content
of the Package file. But the best option from a modeling viewpoint is to
have packages be members of groups, not have groups with packages in them.
Jason
Reply to: