Re: APT broken ?
On Sat, 4 Apr 1998, Jason Gunthorpe wrote:
>
> On Sat, 4 Apr 1998, Dale Scheetz wrote:
>
> > > 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.
>
> If the package was marked as installed then there would be no problem as
> it has met dependancies! Overloading installed to mean 'maybe installed'
> is not a good idea. It changes what hold means and it changes what
> installed means - very bad.
We definitely see this from a different point of view.
I see this as giving me the flexibility to decide when the necessary
dependencies are satified, even when the package database doesn't
adequately reflect that fact. For many dependencies, they become satisfied
at the point at which they are unpacked. It is this fact that allows the
base image to be constructed in the first place.
>
> > I don't see what is wrong with this, as it falls within original
> > definitions of the behaviour.
>
> How so?
>
> Installed - Means that the package is unpacked and configured and is in a
> good state
>
But for many packages, unpacking them is sufficient to satisfy the
dependency. I believe cpp is one of those. Once it is unpacked gcc will
work.
There are sometimes valid reasons not to fully configure such a package.
Most of these have to do with systems built in /usr/local that need to be
integrated with the Debian system, but some of the integration packages
provide daemons that interfere with the system on local.
The major reason, however, is so I can install a library in local, that
fixes a grevious bug in the current Debian library, and still have the
Debian system recognize that the dependency is met.
Libraries are no the only example that I can come up with, but I think you
see the point. Dpkg/dselect has never had a good mechanism for handling
such methods of satisfying dependencies with programs in /usr/local.
Whatever the mechanism for arriving at the satisfaction conditions, I
suspect that the cleanest way to deal with it in the status file is to
declare the package as "installed ok hold" so dpkg/APT doesn't try to
upgrade it, and will still recognize that the package is there to satisfy
the dependencies upon it.
> Hold - Means the package should never be upgraded automatically
>
> Neither of these things say anything about the dependents on the package
> or dependents of the package. I have a flag mechanism in place for several
But they are a mechanism by which I can indicate that those dependencies
are satisfied in a way that dpkg/APT is unaware.
> other things and it might cleanly solve these problems as well without
> overloading well specified functionality.
Why clutter what you are designing when there is an adequate mechanism
already available. The desire to know all the details of the install, by
the package manager, is likely to yield an inflexible system. I'm just
looking for more "freedom" and flexibility.
No "right answer" works in all contexts.
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
Reply to: