<p>Reverse dependencies can mean different things. The current implementation answers these questions:<br>
1. What are the packages for which the latest version depends directly on a given version of foo?<br>
2. What are the packages for which only previous or deprecated versions depend directly on a given version of foo?<br>
3. For which packages do any versions depend either directly and indirectly on any version of bar? (this is what takes 2 seconds to regenerate, as incremental transitive closure wasn't implemented)<br>
4. Which packages are most depended-upon (only direct, or both direct and indirect)?</p>
<p>It seems to me as though 1 is the most important question to answer. This involves knowing, for any package and version, the list of package-version pairs which depend on it. This involves using a fair bit of memory, it seems. Additionally, when a package is uploaded, removed, or changed, the packages which now depend on it also need to be updated.</p>
<p>Another question answered by packdeps is:<br>
5. Which packages depend on a previous or deprecated version of foo but not the latest version? (and vice versa)</p>
<p>This can also be answered by the above data structure. It is currently implemented using nested Data.Maps, which is serialized in the database. There are some opportunities for trimming and optimization.</p>
<p>Best,<br>
Matt</p>
<div class="gmail_quote">On Fri, Aug 24, 2012 at 3:36 PM, Erik Hesselink <span dir="ltr"><<a href="mailto:hesselink@gmail.com" target="_blank">hesselink@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Ian,<br>
<br>
Looks great, thanks for the work! One question: I see the reverse<br>
dependencies have been disabled, darcs says for 'performance<br>
problems'. Do you have some details? Do you think it is hard to fix?<br>
<br>
I wouldn't mind doing some permission granting for the testing period,<br>
by the way.<br>
<span><font color="#888888"><br>
Erik<br>
</font></span><div><div><br>
On Fri, Aug 24, 2012 at 5:17 PM, Ian Lynagh <<a href="mailto:ian@well-typed.com" target="_blank">ian@well-typed.com</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> All the bugs identified in the Hackage 2 server as blockers have now<br>
> been fixed, and I have a mirror of Hackage running here:<br>
> <a href="http://new-hackage.haskell.org/" target="_blank">http://new-hackage.haskell.org/</a><br>
><br>
> I suggest that we proceed with:<br>
><br>
> * A 3 week testing period, to be announced on haskell@ and libraries@<br>
> * Assuming no new blocking bugs are found which justify additional<br>
> testing time, disable uploads to the Hackage 1 server<br>
> * Throw the testing Hackage 2 instance away, and make a new mirror from<br>
> the Hackage 1 server<br>
> * Point <a href="http://hackage.haskell.org" target="_blank">hackage.haskell.org</a> at the new Hackage 2 instance<br>
><br>
><br>
> I think that a 3 week testing period will be sufficient as I expect most<br>
> testing will happen in the first week or two, or the last few days, so<br>
> any extra time is essentially wasted. I was actually initially going to<br>
> propose 2 weeks, but given the timing of ICFP et al I think an extra<br>
> week is justified.<br>
><br>
> The reason I propose throwing away this test instance is that I think<br>
> it's important that people are able to test uploading, and therefore<br>
> uploading dummy packages and dummy versions should be encouraged.<br>
><br>
><br>
> Does that plan sound reasonable to everyone?<br>
><br>
> Is anyone willing to volunteer to be an admin for the new Hackage server<br>
> please? (people need to have an admin add their account to the uploaders<br>
> group before they can upload).<br>
><br>
><br>
> A couple more notes:<br>
><br>
> The mirror is a week or two old, so the latest package uploads won't be<br>
> on it. I don't plan to set up continuous mirroring, as I think it may be<br>
> more useful for people to be able to upload new versions to both servers<br>
> themselves, for testing.<br>
><br>
> The documentation builder has built (or failed to build) docs for the<br>
> latest versions of all packages, but it's still working through older<br>
> versions. It will therefore take up to 35mins before it notices that a<br>
> new package has been uploaded, and builds docs for it.<br>
><br>
><br>
> Finally, I would like to thank the Industrial Haskell Group<br>
> (<a href="http://industry.haskell.org/" target="_blank">http://industry.haskell.org/</a>) for funding this work.<br>
><br>
><br>
> Thanks<br>
> Ian<br>
> --<br>
> Ian Lynagh, Haskell Consultant<br>
> Well-Typed LLP, <a href="http://www.well-typed.com/" target="_blank">http://www.well-typed.com/</a><br>
><br>
><br>
> _______________________________________________<br>
> cabal-devel mailing list<br>
> <a href="mailto:cabal-devel@haskell.org" target="_blank">cabal-devel@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/cabal-devel" target="_blank">http://www.haskell.org/mailman/listinfo/cabal-devel</a><br>
<br>
_______________________________________________<br>
cabal-devel mailing list<br>
<a href="mailto:cabal-devel@haskell.org" target="_blank">cabal-devel@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/cabal-devel" target="_blank">http://www.haskell.org/mailman/listinfo/cabal-devel</a><br>
</div></div></blockquote></div><br>