tech-pkg archive

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

Re: make replace



On Jul 9, 2010, at 0:44, David Holland wrote:

> On Wed, Jul 07, 2010 at 06:59:02PM +0200, Dieter Baron wrote:
>>  David and your stance seem to be "I'll do whatever I feel like,
>> and the package tools better deal with the fallout."  I don't think
>> this is constructive, nor do I think it is needed to accomodate
>> pkg_rr.
> 
> No, all I have said is that the package database should reflect what
> the package tools have done. If running the package tools according to
> their directions results in a corrupted package database, that
> constitutes a bug in the package tools.

  With that I can agree.

> You and/or Joerg appear to have conceived the idea that the existence
> of an installed package whose installation requirements are no longer
> met somehow constitutes an inconsistency in the package database
> itself. However, this is not true.

  But it is: the consistency constraint that a package's dependencies are 
satisfied is violated.  Agreed, it is quite a different kind of inconsistency 
than e.g. dangling dependency pointers or a corrupted database.

> The package database already has a
> way to consistently represent at least one case of such packages and
> this mechanism has been deployed and working perfectly well for
> several years.

  Indeed it has such a mechanism.

> Whether the package database will in the future need to store more
> detailed information, or have a more sophisticated model of broken
> packages, is an open question. But it's not a question that we're
> going to make any progress on until this fundamental apparent
> misconception is resolved.

  If you insist, we can use a different term for this kind of inconsistency 
(violated invariant, maybe?).

  The point of my mail was, which invariants that are maintained by 
pkg_add/pkg_delete without special flags (like -u, -f) need to be lifted for 
make replace/pkg_rr to work.

  So far I have: the dependencies need not be satisfied.  This is marked with 
unsafe_depends.

  Any others?

yours,
dillo



Home | Main Index | Thread Index | Old Index