Re: Ignoring dependance on "important" packages?

["Martin Bialasinski" <martin@internet-treff.uni-koeln.de>]

>> "Adam" == Adam Di Carlo <adam@onshore.com> wrote:

[ not installing packages - just getting their dependancies ]

Adam> And why exactly do you want to do that? 

Jason said he could make apt recognised a Meta-Package: yes flag in
the control file. These packages will be handled as usual with apt,
but when it come to calling dpkg for installation, they will not be
passed along.

So after installing a task package that uses this package, it is no
problem to remove some of the packages pulled by the task. Otherwise,
the installed task package will prevent this.

Adam> I could see how getting continuing updates of "metapackages"
Adam> would be useful (i.e., task-sgml-dev, meaning, give me all the
Adam> SGML development tools; as new packages are added, I add them to
Adam> the metapackage).

This is indeed a conflicting goal. There is a easy way to solve this
(the other way around is clumsy):

The user can enter all task packages to track in
/etc/apt/task-packages. apt-get upgrade and apt-get dist-upgrade will
then automatically track these packages just as they would be
installed.

So tracking a task package is no problem, removing some of the
packages pulled by the task package is no problem as well. This also
allows for using the task packages as one-time selection helpers (the
empty netscape packages have been created with this in mind).

With the current way, tracking a task package is possible. Removing
some package can result in a conflict (dpkg) or conflict resolution
screen (dselect), where one has to remove the task package. This is a
critical thing that should be avoided (especially for new users).

When the package frontend knows about the "task" status of a package
further things are possible. First, one could switch the programm into 
"tasks" mode, then:

a) one shot installation

b) Tracking of a task package

c) Tracking of task package, with some dependencies excluded.

This can then look like:

   * -- task bar      -> one shot installation

   + -- task baz      -> partial one-shot installation
      + package A     -> install
      + package B     -> install
      - package C     -> don't install

   X -- task foo      -> will be tracked completely

   x -- task bonk     -> will be tracked partly (new pkg. on task
      x package D          updates will be installed)
      x package E
      - package F

See? This extra semantic will do some good I believe. And if Debian
continues to grow that fast, such a thing is badly needed.

Ciao,
	Martin