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

Re: YADW (Yeat another dpkg wishlist)



On Tue, 14 Oct 1997, Dale Scheetz wrote:

> Thanks for your reply. It is clear that you guys have been thinking about
> this. I have worried over this problem for a while myself and have a
> completely different approach.
> 
> Dpkg has a current behavior for -iGROEB that I would like to modify.
> Currently under this option, dpkg starts with the archive (possibly using
> the available file) and walks through the files in its view in the order
> that they appear in the file system. Once it "finds" a package, it checks
> the status file to see what is allowed before performing the install.
> Dselect does nothing more complex than to edit this file based on what the
> interface collects from the user.
> 
> If dpkg could be either provided a new option or have -iGROEB modified the
> install could be managed with existing code and handle the "ordering"
> problem. All dpkg needs to do is drive itself from the status file. This
> file contains directives for installation and purging (as well as Hold and
> others). If dpkg were driven by this file instead of the archive, then
> ordering the entries in the status file so that they satisfied the
> dependencies would create a "clean" oneshot pass on the installation
> process with no changes to dselect.
> 
> How does this idea integrate with current plans for Deity?

It basically means Manoj would have make a patch for dpkg instead of
making new code for Deity. This has two negative side effects, Deity still
needs the dependancy code, so we have a fair amount of duplication and
dpkg gets larger and more complex and starts to infringe on UI issues. Ie
right now with -iGROEB dpkg will install a new version unless the package
is held, Deity allows a wider range of specification.

In an ideal world this code would be in a nice little library and dpkg and
Deity would both happily call it to do the needed things. But since it is
quite unlikely that we will be able to get anyone to rewrite enough of
dpkg so that it can use our library Ian will end up rewriting our code and
we will have two (supposidly) identical views of how to do dependancy.

Imagine how bad things will be when we add a new feature, Deity's pkglib
and dpkg will have to both be made aware of it. Yucky eh? 

The placement of the pkg order code doesn't really matter wheather dpkg or
deity does it (dpkg would of course be the better choice) but it will rely
on our core dependancy anylsis code and cache format to do all of it's
processing, ie once written it should very rarely need to be changed in
light of new features. This makes it hard+complex to integrate into
dpkg.

That is one possibility, there are a few others. 

Jason


Reply to: