Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Wed, Nov 23, 2016 at 5:19 PM, Didier 'OdyX' Raboud <odyx@debian.org> wrote:
> The TC had an IRC meeting yesterday [0], and I (was) volunteered to wrap up
> the different outcome possibilities, which would help forming our opinions.
> Not all these options are exclusive, or would need an actual TC decision.
>
> Here we go:
>
> A) 'global' stays maintained as it currently is.
>
> This would imply:
> - no new 'global' upstream release before stretch,
> - no 'htags removal' warning in stretch,
> - possibility for the maintainer (and/or other interested parties) to start
> maintaining a 'global6'; this wouldn't offer any guarantee for a more
> recent version of 'global' in stretch. This would also imply having two
> 'global' packages in certain suites.
>
> B) A fresher version of 'global' is uploaded to experimental 'soon'
> (with or without interested parties' help; with or without a TC decision)
>
> This would imply:
> - any interested party would file (and close) Debian bugs for issues and
> regressions (with appropriate severities), to make the 'fitness for a
> stable release' assessment easier, and earlier.
>
> C) After the release of stretch, a fresher version of 'global' is uploaded to
> unstable with the explicit goal of making it available in buster.
>
> This would imply:
> - any interested party would file (and close) Debian bugs for issues and
> regressions (with appropriate severities), to make the 'fitness for a
> stable release' assessment easier.
> - after migration to testing, this would make the fresher version of 'global'
> available for backporting to stretch-backports.
> - the version of 'global' released in stretch could carry 'htags removal'
> warnings;
>
> D) A fresher version of 'global' is uploaded to unstable 'soon', targetting
> stretch (with or without interested parties' help; with or without a TC
> decision)
>
> This would imply:
> - overruling the 'global' maintainer's decision (§6.1.4, implies 3:1 majority
> in a TC vote);
> - any interested party (including the maintainer) would file (and close)
> Debian bugs for issues and regressions (with appropriate severities), to
> make the 'fitness for a stable release' assessment easier.
> - that this fresher version of 'global' would reach 'fit for release' status
> before the Stretch release.
>
> E) the 'global' package is handed to other maintainer(s)
>
> This would imply:
> - overruling the 'global' maintainer's decision (§6.1.4, implies 3:1 majority
> in the TC vote);
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.
Gnu Global is a source code tagging system similar in functionality to
ctags or cscope. It allows searching for symbol definitions and use in
the codebase by splitting the functionality into two steps -
* Indexing - This is a offline step where an index of source code
symbols definitions and references for a code base is created. This
functionality is provided by "gtags" binary (part of upstream global).
Indexes (or is it indices?) typically live in the source tree (they
don't need to).
* Searching - Once the code base is indexed, the indexes can be used
to search for symbol definitions as well as query locations where the
symbol is referenced. This can be done using the "global" binary
(again provided by upstream). Also there are various integrations with
commonly used editors - emacs, vim, elvis, etc - that internally
invoke global for their symbol lookup requirements. So if you are a
developer who would like to use global to navigate your way through a
large code base a common way to use it would be to use "gtags" and the
editor integration of your choice.
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.
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 and for which
there are patches in the debian package. In recent versions (> 6.4,
Apr '15), upstream has dropped support for generating scripts that
expect to be written to system cgi-bin folder. As demonstrated by
wookey[1], it is still possible to use the dynamic html option as a
non-root user by running a web server using higher numbered ports.
IIUC, Ron's patch removes the need for htags to write to system
cgi-bin (by providing an indirection mechanism for incoming http
requests).
Serving dynamic source index via system cgi-bin is, IMHO, a small part
of the functionality provided by the package and should be seen as
such while making any decision regarding the package.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816924#65
>
> --
> Cheers,
> OdyX
>
> [0] http://meetbot.debian.net/debian-ctte/2016/debian-ctte.
> 2016-11-22-16.59.html
Reply to: