This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 04/11/2013 11:00 AM, Christopher Faylor wrote:
Throwing graphviz at a full cygwin package dependency graph would make a pretty effective DoS attack. Smaller graphs are cheaper, but still consume non-trivial compute. Given how slowly the online regexp package search goes, I'd hesitate to give users more ways to overload the server...On Mon, Nov 04, 2013 at 09:32:10AM -0500, Charles Wilson wrote:On 10/30/2013 9:51 AM, Ryan Johnson wrote:On 30/10/2013 8:48 AM, Charles Wilson wrote:Yeah; even for my stripped-down version, I need to pre-process the setup.ini and remove all mentions of cygwin, libstdc++6, libgcc1, etc. The ncurses DLLs are also a huge nexus. (It's probably easier to exclude those nodes by mucking with the perl, but...)Quick question: do you have 1+ known-big-unwanted packages and need to know who's pulling them in, or are you hoping to take some cut of the graph that gets as many desirable packages as possible given the space constraints? The graph-building script here is good for the latter, but I had the impression you were doing the former; if so, my script might get you to an answer faster by avoiding information overload.A combination of the two, actually. I've used both David's script and yours in concert. In addition, I've modified David's script to color the nodes based on origination, and to exclude or collapse 'Base' and/or 'required-by-Base' packages. I've got a few cleanups, and then I'll share the result. It's already helped me generate a few re-packaging requests I plan to post over on cygwin-apps...Is this packagable? It sounds pretty interesting. Would it be crazy to generate this and make it available on the cygwin web site? Or would the dependency graph generation overload sourceware.org?
What about calling out to graphviz from setup.exe (if found in %PATH%), as a replacement/supplement for the flat list of dependencies it currently reports? That would put all processing on the client, and limit the "big data" problem, as the graph only contains packages a user is currently trying to install.
Alternatively, cygcheck could gain a new -g option to dump subsets of a dependency graph, extracted from setup.ini, in some appropriate format like .dot:
`cygcheck -D -g python' would emit the graph of packages that python depends on `cygcheck -R -g texlive,xorg-server' would build a braph of packages that pull in either of texlive or xorg-server (reverse dependencies) -D -R -g would follow dependencies in both directions, and -g would be shorthand for -D -g; probably -D or -R by itself implies -g.
The actual work could be done by calling out to a scripting language that ships with cygwin. Awk would probably be able to, and perl certainly could.
/daydreaming Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |