Dear Sven,
     in EDOS we have built quite a few other tools, which are not yet
finalized to the point of being widely usable outside the project (more on
this below), that provide a first solution of the problem you mention...

 - history.
   This is a tool, written by Berk Durak, that incorporates Jerome's solver
   algorithm and has a command line interface that provides an algebraic
   language to manipulate sets of packages: select packages available on day d,
   intersect, union, get latest versions, compute dependency closure,
   testing for installability, etc.

   Now, if you look at chapter 4, section 4.2 of
   
http://www.edos-project.org/xwiki/bin/download/Main/Deliverables/edos-wp2d2.pdf
   you will see the description of an actual transcript of a session with the
   tool that tries to build a small self-contained distribution containing a
   given set of requested packages.

 - anla.
   This is usable, online, at http://brion.inria.fr/anla
   It is a webified, history-aware tool written by Berke and incorporating
   Jerome's solver and Jaap Boender's package readers.
   This could be, IMHO, of huge help for distribution maintainers, and is
   already usable for Debian (since the tool is following the Debian pool
   now).

What is up to now under heavy development/testing for these two tools is the
backend that builds the huge database containing the historical information for
all the packages, day by day... Berke has been testing a relational backend, but
it is too slow, so he is now moving to a more efficient, but custom-built,
solution. Until this backend is finalized, it is a bit complicated to deploy
history or anla...

We definitely will need packages for history and anla too :-)

--Roberto

>>>>> "Ralf" == Ralf Treinen <[EMAIL PROTECTED]> writes:

    Ralf> Hi Sven, On Fri, Apr 28, 2006 at 12:04:02AM +0200, Sven Mueller wrote:
    >> Ralf Treinen wrote on 27/04/2006 21:53: > Package: wnpp > Severity:
    >> wishlist > Owner: Ralf Treinen <[EMAIL PROTECTED]>
    >> > 
    >> > * Package name : debcheck > Version : as of 2006/3/19 > Upstream Author
    >> : Jerome Vouillon <[EMAIL PROTECTED]> > * URL :
    >> http://www.pps.jussieu.fr/~vouillon/
    >> 
    >> There is one "small" wish (actually I don't know wether it is a small or
    >> large one, considering the work already done in debcheck/rpmcheck) I
    >> have, which you might want to implement and/or forward to $Upstream:
    >> 
    >> It would be quite nice if the tool had an option to do the following:
    >> Given the Packages file (or other compatible list of packages) on STDIN
    >> and a set of "seed" packages on the commandline, print out all the
    >> packages needed to fulfill the dependencies (if all dependencies can be
    >> fulfilled - error out if not).
    >> 
    >> This would be of use on many occasions, most notably when you try to
    >> build a minimal repository which contains all needed packages for a given
    >> set of packages you want installed. In my case, it would help to build an
    >> automated installation CD for Debian with some customized and/or
    >> additional packages. Currently, when I add a new application, I have to
    >> manually check the dependencies. Would be extremely nice to find a way to
    >> automate this.

    Ralf> What you describe is indeed one of the goals of the edos project
    Ralf> (http://www.edos-project.org/xwiki/bin/view/Main/WebHome) where the
    Ralf> debcheck tool (and many others) comes from. In the context of the edos
    Ralf> projec we call this problem "thinning" of a distribution.  The problem
    Ralf> seems to be beyond debcheck's realm. There is work in progress on this
    Ralf> issue but so far there is no completely satisfying solution. In
    Ralf> particular we would like to find a minimal solution with respect to
    Ralf> some reasonable metrics (number of packages, size of packages,
    Ralf> ...). How important do you think would be minimality of a solution? Or
    Ralf> what would be your criterion for an optimal solution to the problem?

    Ralf> The use case you describe suggests to me a variant of the problem
    Ralf> which might be easier: Extend a given distribution by just a small set
    Ralf> of packages and their dependency closure. In this case it would be
    Ralf> sufficient to find a solution which is only "locally" optimal (that is
    Ralf> optimal among those that preserve the previous calculated
    Ralf> distribution). Would that be sufficient for your purpose?

    Ralf> -Ralf.

-- 
--Roberto Di Cosmo
 
------------------------------------------------------------------
Professeur
PPS                      E-mail: [EMAIL PROTECTED]
Universite Paris VII     WWW  : http://www.dicosmo.org
Case 7014                Tel  : ++33-(0)1-44 27 86 55
2, place Jussieu         Fax  : ++33-(0)1-44 27 68 49
F-75251 Paris Cedex 05
FRANCE.                  
------------------------------------------------------------------
Attachments:
   MIME accepted
   Word deprecated, http://www.rfc1149.net/documents/whynotword
------------------------------------------------------------------
Office location:
 
Bureau 6C15 (6th floor)
175, rue du Chevaleret, XIII
Metro Chevaleret, ligne 6
------------------------------------------------------------------              
                                   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to