On Fri, Apr 11, 2014 at 09:38:54AM +0100, Punit Agrawal wrote: > Hi Shigio, > > Thanks for the explanation. > > On Thu, Apr 10, 2014 at 1:03 PM, Shigio YAMAGUCHI <shi...@gnu.org> wrote: > > Hi Punit, > >> <localstatedir> resolves to '/usr/var' which throws a lintian warning > >> as this location doesn't conform to Debian File Hierarchy Standard. > >> Can you please explain what is the role of this folder and how it is > >> used? Perhaps there is a more standard debian location where I can > >> install this to. > > > > The role of <localstatedir> is defined in the GNU's standards. > > Please see the following site: > > http://www.gnu.org/prep/standards/html_node/Directory-Variables.html > > > > Htags uses '<localstatedir>/gtags/sitekeys/' as a database of > > project directories. > > > > So the aim is to have a mapping from sitekeys to actual project > directories containing the generated HTML. > > >> From my understanding, bless.sh writes the location of the current > >> folder (pwd) into '<localstatedir>/gtags/sitekeys/<key>'. Can you > >> explain how this information is used then? > > > > The current folder means 'HTML' directory in the project. Since the > > --system-cgi option uses CGI programs in the system area which is > > out of the project, the programs need a help for reach there. > > > > Ok. Am I correct in understanding that the actual system cgi script is > not provided by global but it is to be created by the user or system > administrator.
Global creates everything that is needed, but installing it to the system requires privilege that an ordinary user should not have. Which means we need a secure and sensible interface for someone with that privilege to exercise it, in a way that meets the normal distro expectations and standards. A generated script that the user is required to run as root, or making a privileged system directory 777 writable is not such an interface. If people want to do that on their own systems that is fine, but the distro packages should never be recommending or requiring this. > I am looking to see if there's an obvious way to package this. There is a mechanism for doing this in the existing package. If something equivalent to that was integrated upstream, none of this would be a problem anymore. > I might resort to turning this feature off in the first update and then > add it to the package as I understand better what is needed on the > packaging side. NACK. Saying "I don't need this, so I'm just going to remove it for everyone else to rush out the bits that _I_ want" is not an acceptable solution. If that's all you want then you can make your own local packages easily enough. I am very interested in seeing this all fixed, but someone is going to have to find a middle ground that both meets the minimum sensible expectations for distro Best Practice for this, and that Shigio is willing to accept. Several of us have tried several times, but maybe you will have more luck with that. But we need to sort this out. Sweeping it under the rug is just code for "This will never happen", so I will strongly object to any upload that does this. Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
