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

Re: APT broken ?

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
> --


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: pgpgd8bpVF_0x.pgp
Description: PGP signature

Reply to: