<div class="gmail_quote">On Wed, Apr 15, 2009 at 10:54 PM, alkos333 <span dir="ltr"><<a href="mailto:me@alkos333.net" target="_blank">me@alkos333.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I have a queue named "all" which contains all of my currently<br>
installed packages in appropriate order (as far as dependencies are<br>
concerned). It took me quite a while to construct the the queue and<br>
then do several runs to sort out dependencies.<br>
<br>
What about creating a feature that would first queue all of the<br>
currently installed packages into the queue. Second, it would scan<br>
their README files and look for name hits and move the packages with<br>
those names before the package whose README is being scanned.<br>
Basically, I'm in no way trying to automate the dependency check<br>
because there were still be conflicts, but at the very least, this<br>
will get the overall queue as close to the functioning state as<br>
possible and the admin can then finish the rest.<br>
<br>
This was just an idea that hit me as I was creating a back-up queue<br>
for recompiling all of the SBo package after an update let's say.</blockquote><div><br></div></div>Unfortunately, this is not as simple as it looks. It's very easy to have circular "dependencies" ("X needs Y" / "[Y] is a dependency of X"), as well as broken dependencies ("You cannot install X and Y together").<br>
<br>Anyway, why a single queue? I think storing one queue per (relevant) package would be far more flexible, given that sbopkg makes loading and merging multiple queue files really easy. And of course, somebody could also build up a queue archive.<br>
<br>-- <br>Mauro Giachero<br>