Re: Bug#167513: the lack of consultation or discussion regarding this change is not good
> Seriously. We have been discussing this issue all 3 of us and we agreed
> that we will not implement this change until a proper discussion will take
> place where both users and developers are involved. Thom was only
> spreading our voice around so addressing him directly is not proper imho.
Just to be accurate... I brought this idea to the apache maintainer(s)
when I first had it and got a general reply of "don't bother us with this
until it's policy". So, away I went.
I also note the irony in Thom expressing his great displeasure at not
being involved in the discussion that led to the policy change and yet
this is something that "all 3 of [you]" have been discussing and didn't
choose to involve me.
> I don't know how many of you have considered the fact that atm Debian
> ships 507 cgi scripts, in 115 pkgs, only in /usr/lib/cgi-bin WITHOUT
> considering other pkgs that can refer to them or their config files and so
> on.
I'm well aware of the difficulties. I'm also aware that there was little
thought put in to this placement in the first place, which is why we're
now faced with an ever growing problem.
I'm trying to minimize the impact by keeping cgi-bin where it was for now,
so the transition is a smooth one. If you want to make the argument that
even new installations should keep cgi-bin in the traditional place for
this release, then make that case. It could be changed to <webroot>/cgi-bin
once the majority of packages have made the conversion.
Right now we have a fundamental problem that Debian goes against the
established mechanism of allowing webmasters to use /cgi-bin/, or at
least we must give up debian package scripts to do so.
> Are you dealing to test and fix all of them if needed?
This is not really a difficult change. It's pretty much a global search &
replace of "cgi-bin" to "cgi-lib" for packages that use that in their URLs.
But, because of the slow change-over of existing /cgi-bin/ to the proper
location (only new installations would do that), any instances that are
missed or done incorrectly will onlyaffect a small number of users, all
of which are using new installations anyway and should be expecting such
things.
> I don't really see the advantage of such a change compared to the amount
> of work that needs to be done in order to implement it.
It is a lot of changes, but they're mostly, if not completely, just small
changes and distributed over a large number of maintainers.
Brian
( bcwhite@pobox.com )
-------------------------------------------------------------------------------
If you want people motivated to do a good job, give them a good job to do.
Reply to: