Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Punit Agrawal writes ("Bug#841294: Overrule maintainer of "global" to package a new upstream version"):
> In offline discussions with Wookey, we came to the realisation that
> reading the various bug reports (including this one) it is not very
> clear how global (upstream) is structured, the functionality it
> provides and bits that are holding back the debian update.

Thank you for your clear and excellent explanation.


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 ?

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 ?

 - Run the htags server on a high-numbered port somehow.  (Is there
   some kind of simple scriptery provided, to do this?)

 - 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 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.


FAOD none of this changes my view about the proper resolution of this
TC petition.  But answers might help clarify the discussion.

Thanks,
Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.