[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: About the Breaks: field.

Guy Maor <maor@ece.utexas.edu> writes:

> Conflicts is like a reverse Depends.  It affects package
> configuration.
> Breaks is like a reverse Pre-Depends.  It affects package unpacking.

Some investigation reveals that I was wrong.  A package which
conflicts with a package whose state is unpacked or higher won't even

One major problem with Conflicts is that dpkg doesn't detect if the
Conflicts can be resolved by reordering package unpacking.  In fact,
dpkg doesn't reorder package unpacking, only package configuration.

Santiago's proposal said that Breaks would cause a reorder of package
unpacking.  I see no reason why it cannot be added for Conflicts.
Probably that's what Ian meant.

So the all too common case of:
  fooA_1 and fooB_1 are installed.
  We'd like to upgrade to fooA_2 and fooB_2, but we MUST upgrade fooA first.
can't be done automatically!!

Ideally, two things have to happen in dpkg:

1. Unpacking is reordered according to Conflicts lines.

2. New unpack-configure cycles are introduced to support Pre-Depends.
The current way of doing pre-dependencies is rather crude (with
--predep-package), and neither version of dpkg-ftp even supports it!

Unfortunately there's a nasty bout of Dpkg Programmer's Disease going
around.  Anyone that looks at the source long enough to have a vague
idea of what's going on instantly drops off the planet.  I fear the
worst...  ;-)


TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: