On 2016-11-30 16:56 +0000, Ian Jackson wrote: > On to some questions it raises for me: > > > Optionally, "htags" can generate a dynamic index (which reduces disk > > space usage) but requires an http server setup to be able to serve the > > pages. In this scenario, you will also need to be able to execute CGI > > scripts as the symbol lookup is done when serving the http request (as > > opposed to pre-processed when using static pages). > > > > And this last bit (integration with system web server) is the > > functionality that had security concerns raised by Ron [etc.] > > So, to be clear, it is this functionality which is dropped in the > package that you and Wookey uploaded to experimental/delayed ? Said package is available as of today: https://buildd.debian.org/status/package.php?p=global&suite=experimental And that functionality was left in as it was a self-contained patch, pending determining whether in fact it remained useful/compatible or not. So you still get htmake and htconfig commands. However I have now done some checking, and no it doesn't work any more because it uses the btreeop command, which has been removed in current upstream, and the --action option to htags which is also gone. We are having a think about whether this code can be hacked about a bit to remain useful or if its approach is simply no longer relevant, given upstream changes. And I just said replying to Sam, there is a lot be said for not diverging significantly from upstream, because there is significant overhead in doing so. So this patch is currently likely to get dropped unless someone works out a way to make it work/be useful. > But AIUI this functionality remains: > > > In addition to the above mechanisms, upstream also provides "htags" > > which can be used to generate an HTML version of the index. "htags" > > uses the index created by "gtags" and the source tree as input and > > generates html files which allow you to navigate the source code in > > the browser. By default, htags generates static pages which means you > > can browse the code in a local browser without requiring a web server. > So the impact for a user of the existing functionality the regression > is not that their entire workflow is disrupted. > Rather (unless the software is improved) they have these choices: > > - Put up with pregenerated html indices. Is the only downside > of this that they use additional disk space, and presumably > cpu time to generate them ? Correct. And they can easily be symlinked from say /var/www/html/global/<package> to make them a) accessible from system webserver and b) conveniently listed. The static HTML is 7G for a kernel source tree. The dynamic version is 3.3G. (or 4.8G with the suggested '--suggest2' options) So there is a x2 space overhead. > - Run the htags server on a high-numbered port somehow. (Is there > some kind of simple scriptery provided, to do this?) There is an example in the NEWS file, which should go in the man page. It's trivial: cd HTML; python -m CGIHTTPServer or cd HTML; python3 -m http.server --cgi Then browse to http://localhost:8000/ > - If the machine is not really multi-user, tear down the security > boundary defending the webserver from their user account, and give > their user account access to the webserver cgi directory (or plumb > it in with symlinks). (Are there any instructions or scripts for > this?) (Also this assumes that the source code is not super > secret.) I've just started playing with this to see what can be done (bearing in mind the question of how much effort we should put into this sort of upstream divergence anyway). Simply symlinking /var/www/global/sourcetree to <whereever/sourcetree/HTML> from gives you a convenient list of globalised htags to look through if they are static. The issue with dynamic htags (and the search functionality) is that by default your web server won't run .cgi scripts in arbitrary directories (for good reasons). I don't know if we can have a central .cgi that 'sources' the global.cgi or completion.cgi in the htags sourcetree/HTML dir and uses it, or if that's still not actually a good idea. Possibly something nifty with apache config scripts would work. Suggestions welcome. > I don't know much about this, but several of these choices seem likely > to be plausible choices for many if not most current users of htags. Right. I think the functionality upstream provides is fine. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
Attachment:
signature.asc
Description: Digital signature