Ralf Treinen wrote on 28/04/2006 09:48: > Hi Sven, >>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). > > What you describe is indeed one of the goals of the edos project > (http://www.edos-project.org/xwiki/bin/view/Main/WebHome) where > the debcheck tool (and many others) comes from. In the context > of the edos projec we call this problem "thinning" of a distribution. > The problem seems to be beyond debcheck's realm. There is work in > progress on this issue but so far there is no completely satisfying > solution. In particular we would like to find a minimal solution > with respect to some reasonable metrics (number of packages, size > of packages, ...). How important do you think would be minimality > of a solution? Or what would be your criterion for an optimal > solution to the problem? > > The use case you describe suggests to me a variant of the problem > which might be easier: Extend a given distribution by just a small > set of packages and their dependency closure. In this case it would > be sufficient to find a solution which is only "locally" optimal > (that is optimal among those that preserve the previous calculated > distribution). Would that be sufficient for your purpose?
I'm not certain what you describe here. What I would need as an output is a sort of minimal set of packages. The Definition of a minimal set could divert under certain circumstances (minimal in size or in number of packages), but for me it would be of no importance wether I would get the minimal number of packages or the set of minimal size. Let's assume that apart from what Debian defines as the core set of packages, my repository has these packages (format: "package: Dependencies (size)"): a: b, c|d (1) b: d|c (1) c: e (2) d: (4) e: (1) Assuming that there are no conflicts, and I specify "a" as the 'set' of seed packages. Now there are a number of possible solutions: a,b,c,d,e (9) a,b,c,e (5) a,b,d,e (7) a,b,d (6) The first is trivial: If I install all packages, all dependencies are fulfilled. The second if the optiomal solution if space is the criteria, the fourth the optimal solution if number of packages is the criteria. The third is a non-trivial and non-optimal solution. I personally wouldn't care wether I get the second or fourth solution, as long as the set is minimal to either the number of packages or the size of packages criteria. However I need to be able to specify the seed packages and the list of available Packages at run time. I do not care about what the history of my archive might have produced at some other time of its existance though. And I would be actually quite satisfied if the solution I get is nearly optimal to either criteria, I don't care if I could have a set with 5% less packages (or package size), as long as the set I get doesn't contain more than 10% of unneeded packages. Roberto: I'm not sure I understand your descriptions of "history" and "anla" correctly. But from glancing over the PDF you referenced, I guess what I need is actually an equivalent to something close to the thing described in 4.4.2 (A first solution). My ideal tool would take a packages list from STDIN (like debcheck does) plus a set of packages from the commandline (as a list in $need). What I would then appreciate to get is equivalent to the following expression if I understand the syntax right: $essential <- unit(filter(packages, $p -> is_essential($p))) $target <- $essential | $need $result <- install(latest($target), packages) I'm not worried about certain (known) packages missing from that $result set (like kernel or bootloader - which are normally not directly depended on) unless they were specified in the list of seed packages. Regards, Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
