Re: APT broken ?

[Dale Scheetz <dwarf@polaris.net>]

On Sat, 4 Apr 1998, Jason Gunthorpe wrote:

> 
> On Sat, 4 Apr 1998, Dale Scheetz wrote:
> 
> > On Sat, 4 Apr 1998, Jason Gunthorpe wrote:
> > 
> > > 
> > > On Sat, 4 Apr 1998, Raul Miller wrote:
> > > 
> > > > Jason Gunthorpe <jgg@gpu.srv.ualberta.ca> wrote:
> > > > > APT will -never- allow you to do something that results in broken
> > > > > dependancies, it does very complete checking of this at all stages of
> > > > > the installation.
> > > > 
> > > > How do you mark a package as "outside the scope of APT"?
> > > 
> > > There is not a way presently. That might be a good solution to the problem
> > > with desired unmet dependancies... Will think about it.
> 
> > What happened to Hold, from dselect? Isn't APT satisfying such
> > compatibility issues?
> 
> APT interprits hold exactly as hold means, do not install a new version of
> this package [and it only does that on upgrade or dselect-upgrade
> commands].
> 
> Hold does not mean that the package's broken dependancies are okay, and it
> probably never should mean that.
>  
> > I would suggest that packages marked "on hold" should be considered to
> > satisfy any dependencies on them. This would provide a mechanism for
>                           
> On them?? I think that is a serious abuse of what hold means. Their own
> dependancies I could relucantly accept, but not dependancies on them.
> 
> My current feeling is to make a flag that completely removes a package
> from APT's view of the system, as far as APT is concerned it does not
> exist [and all dependancies on it will fail]. That is probably the best
> solution to the orignal problem.
> 
> What you are talking about is something completely different and might be
> handled by another flag - I would have to consider that some more -
> it would certainly be a very dangerous flag to use.
> 
> Hold is certianly not the correct thing for either sitatuation.

If the package is marked in the status file as installed and on hold, I
would hope that the packages that depend on this package will have those
dependencies satisfied.

I don't see what is wrong with this, as it falls within original
definitions of the behaviour.

Later, 

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org