On Sun, Apr 05, 1998 at 02:04:02PM -0400, Dale Scheetz wrote: > 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. > Isn't what equivs does? > > > > > 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. > I don't think it's a good point. dpkg considers the dependencies fullfilled because it *will* configured it sooner or later... However, if configured failed, the system is considered broken and broken packages are Bad Thing. > 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. > IMHO, the only thing missing in the debian schemes is a special `Provides: <package> (=version)' who can resolved dependencies with version (notes that only the equal sign is meaningful here and <package> should be a real package name, not a virtual one). This is a lot of complex changes but will open Debian to a world of possibility (especially new parallel distributions and more configurability). Also, a tool to manage a special local virtual package (somethings like what equivs done but more attractive and integrated -- read GUI oriented, may be like an APT dialog) will be a step forward for the ease of maintenance of the debian systems. > > 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. IMHO, the solution I proposed has both the flexibility desired by dwarf and the control desired by the APT team. I can give an hand if this feature became essential, although I don't know what kind of help I could give. > No "right answer" works in all contexts. Surely not, but a good middle can be fine too ;) > Dwarf > -- Fab. -- ------------------------------------------------------------------------ Fabien Ninoles E-mail: fab@tzone.org WebPage: http://www.callisto.si.usherb.ca/~94246757 You can get my public key from your nearest public keys server! RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70 ------------------------------------------------------------------------
Attachment:
pgppGucuzELqZ.pgp
Description: PGP signature