On Fri, Apr 11, 2014 at 11:31 AM, Ron <r...@debian.org> wrote: > 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. >
The parameters that htconfig/htmake rely on are not part of upstream htags. So they are broken with recent releases. > >> 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. > Turning off a feature is not my preferred option either. I am the one who's initiated this discussion with the intent of trying to understand the functionality and how to package it. > > 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. > The problem arises due to the expectation that the user needs to write to a priviledged system wide location. Instead, is it not preferable that the user generated content (the HTML folder and cgi scripts therein) be placed in the users web area (e.g., ~public_html) and it is served from there like any other user generated content. No priviledged access is required. Does that make sense? > 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. > Sweeping it under the run isn't my intention. I agree we need to resolve the issue. I'd appreciate your input on how it can be fixed properly. Punit > Ron > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
