Re: Slowdown problem of a Debian package
Hello,
On Fri, 28 Jun 2013 02:12:21 +0930
Ron <ron@debian.org> wrote:
> > Hello again,
> >
> > Ron, I explained that the privilege of the database directory
> > is left to the system administrator. You can change it as you
> > like (user id, group id, permission, or etc).
> > The purpose of 'bless.sh' script is to separate two permissions,
> > that is, for running htags and for updating database referenced
> > by CGI programs. So, if the database is writable, administrative
> > privilege is not needed for running htags.
> >
> > As for 'bless.sh' script, though I know that it looks strange,
> > there is no root user who invokes it without reading. It is
> > important that it is essentially one line script and can be
> > understood in 10 seconds. He will do the same thing by his hand.
>
> It is not acceptable, and certainly not necessary, to provide an
> interface in a distro package with a caveat of "you must audit
> this yourself every time before you run it".
>
> If people want to do that with their own hand-hacked stuff, which
> they do understand all the implications of, that is fine, but this
> is not an assumption you can make for users of distro packages.
> People use distro packages precisely because they don't want to and
> expect not to have to do that sort of thing for everything they use.
In your implementation, all the users of htags must have a update
privilege of the database which is referenced by system CGI scripts.
I just offered a method to separate the privilege from general users.
If the database directory is writable like your implementation,
bless.sh is not needed. So, there is no problem above.
> > The method of using UNIX file system as a key-value database
> > is a way which is used by 'qmail' etc. No file format
> > (no interpretation) is the best for security.
> >
> > Is the problem solved? Are any other problems left behind?
> > It is obscure for me.
>
> If your only suggestions are "this script is fine" and "if you don't
> like it you can chmod 777 the secure directory instead", then no,
> nothing has changed, let alone been 'solved'.
>
> > Supposing your not answering, I would like to say as follows:
> >
> > Now, I would like to expect that somebody in the Debian community
> > take over the maintenance job and release 'Better GLOBAL' as
> > he want. It may include the programs by Ron and Taisuke.
> > I know that they are very motivated things.
>
> We already did this in 1999. In long discussions with you about what
> the best possible solution that satisfied the needs of distro users
> would be. You said you did not want to include those changes upstream
> which was fine, but we agreed on the problems and the best solutions
> that we could arrive at to them.
Let me repeat it in my words.
You told me to adopt your software including two command (htmake and
htconfig) and a configuration file as a part of GNU GLOBAL. I didn't
accept it. There is no agreement. That's all.
> You keep saying "if you don't like it you can fork it", and that is
> fine too, that is what we have done. But you cannot then also complain
> that the fork is not following your new work as closely as you would
> like, when you change many things in incompatible ways, and introduce
> new questionable interfaces.
I agree that there are both merits and demerits in the act of forking.
However, htags is just a application program based on GLOBAL.
I want more WEB application programs which based on GLOBAL to appear.
They will be changed frequently under their freedom.
(There are many Emacs interface though.)
The core of GLOBAL is rarely changed.
> I already discussed this with you when you proposed bless.sh and/or
> chmod 777 as a candidate for replacing what we did in 1999 some months
> back now. I was actually quite excited by the prospect of finally
> having a solution from you that we could use, and only disappointed
> by the details of the actual implementation and how short it fell of
> what was really needed here.
Since you kept silent without refute, I thought you have accepted it.
> I'd be delighted to no longer have to carry a fork of this, but not
> at the cost of introducing _all_ of the problems that the work we
> did together back then set out to resolve. You either need to come
> up with a Real solution, or accept that the incompatible changes
> you have made will make them difficult to import into our fork.
>
> Two of us now have offered you solutions and you say you don't like
> them. That is your right. But refusing to accept that there is
> even a problem will not make that problem go away, or make this
> suitable to be included in the distro in the form you propose.
Although I'm making something like a motorboat, you want to make
another thing like a luxury liner. They are both useful. But it is
difficult to merge them.
Accepting software made by others means taking over the responsibility
to support it. It is not easy.
> If you want to make a genuine effort to fix that, I will give you
> my time to review and package it. But I cannot keep giving you
> time to just repeat the same arguments, with the same refusal to
> fix the problem at the end of them and no real progress to show.
No thank you. Period.
> > On the contrary, I am thinking of the ending support of system
> > CGI by htags, because it is rarely used, and is not so important
> > as a tagging system.
>
> I already suggested that in our previous discussion, but you had
> rejected that too. But if you are reconsidering this, then it
> may actually be the best option of all.
Thinking for a couple of days about user's facilities, I decided
to continue it.
> I personally think that the time to kill off htags entirely has
> now long passed. In 1999 it was relatively unique and possibly
> the best of its breed. Today though, doxygen has long since
> surpassed it for generating hypertext markup for source code,
> and it even has support for using gtags with it. And it does
> not have any of the problems that are at issue here. At all.
Is it true? Since Doxygen invokes htags internally, it has the
same problems in it if they are truly problems.
> I do really think that it would be a much better use of all of
> our time for you to focus on the core thing which global does,
> the tag indexing, and leave the task of generating markup to
> doxygen, making any improvements that may be needed _there_ if
> there is still something missing from it that htags provides.
>
> If htags is gone, then this problem does indeed just go away.
>
> About the only person that I have been aware of who still is
> interested in htags has been Taisuke. My impression also is
> that it is rarely used.
I know many people who use htags. Doxygen also invokes htags
internally. It is the --system-cgi option that I said 'rarely used'.
> So I am interested in any reasons that Taisuke might have for
> why doxygen is not a sufficient solution to use.
Doxygen is a documentation generator. It is really wonderful.
Now, GLOBAL's source code is written in Doxygen style.
Though it is your freedom to say 'not a sufficient solution'
about Doxygen, it is like reading a dictionary as a novel and
saying 'the plot is dull'. It differs from GLOBAL in the purpose.
> If there turns out to be no reason not to use it instead, then
> I very much think that this is the way forward we should follow.
> There is no reason to try to reproduce what it does if it is
> now doing it much better than we do and it has the mindshare of
> many more developers supporting it.
>
> What do you think?
Since your text is long, it is pain for me to read.
It is kind if you say a little shorter.
>
> Cheers,
> Ron
Regards,
Shigio
--
Shigio YAMAGUCHI <shigio@gnu.org>
PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3
Reply to: