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

Re: APT broken ?



Jason Gunthorpe <jgg@gpu.srv.ualberta.ca> writes:
> On 3 Apr 1998, Gregory S. Stark wrote:
> > This is a serious problem and really has to be solved eventually.
> > In particular it makes apt completely useless on this system where
> > I have a couple packages installed but unconfigured because I don't
> > want to install the packages they depend on.
> 
> I have no intention of supporting this in the near future. I suggest you
> look at the equivs package.

No, the equivs package is the wrong solution for this situation. 
It will cause dpkg to think the dependencies are fulfilled and go
ahead and configure the package, even though this is wrong.

> Thinks like this wreck havok with the ordering algorithm and the
> installation sanity checks and if you want to disable those then apt
> provides no benifit for you.

Well, at least I know which packages are broken this way, they tend to be
limitted in scope. That is, I had a couple new emacs packages installed with
the old emacs package, and I have libpam0g and libpam0g-dev without the
runtime pam support because I just wanted to compile against libpam, not
actually use it. This doesn't mean apt can't help keep the remaining
distribution sane. Only packages that depend on any of these packages should
be affected, and then it makes sense for it to insist I fix the problem before
it installs any such package.

> Sounds to me however that in your case the packages you are speaking about
> should recommend/suggest and not depend on the packages in question,
> depends sort of suggests the package is either inoperable or significantly
> broken without the package installed.

Well, in the case of the old/new emacs packages it's my install that's broken,
but that shouldn't stop apt from handling the unrelated parts of the
distribution.

In the case of libpam the package should maybe be reorganized to only need a
Suggests or Recommends, but that isn't necessarily just a matter of changing
the control file. The Depends may well be justified unless the maintainer can
change the package. If I understand the extent to which the package is broken
and want to ignore that apt currently hangs me out to dry.

(Incidentally libpam is a bit of a poor example because I just checked and the
Depends isn't justified, it really ought to be a Recommends or Suggests)

I would strongly urge at least the following:

 0) update shouldn't break at all because of a problem like this.

 1) any package group that doesn't have a dependency relationship on the
    broken packages should simply ignore the situation.

 2) installing a group of a packages that fixes the situation should work.
    
Only the last one appears particularly difficult but I'm not familiar with the
algorithms and appearances can be deceiveing.

greg


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


Reply to: