[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#167513: the lack of consultation or discussion regardingthis change is not good



On Sun, 11 May 2003, Brian White wrote:

> I was not even aware, originally, that there were multiple maintainers
> for Apache.

Ok let's not make a big deal of it :-) small misunderstanding can happen.

> > Speaking as myself now, without wearing the apache maintainer hat, you
> > still don't see the impact this will have to users upgrading from woody to
> > woody+X. The transition can be smooth from sid to sid because it can be
> > coordinated during the time. A user that will upgrade from woody will get
> > all the transition in one shot. No matter what we do in our scripts.
> > Adding an alias just because the installation is already there can make it
> > but the user will never feel the benefit of this change. Without
> > considering that he/she will have to modify all custom scripts to match
> > the new standard if he/she wants to benefits from it.
>
> An individual user doesn't need to feel the benefit of the change for it
> to be a benefit to other users and a benefit in general.  It may even
> be a benefit to the user who didn't notice it at some point in the future
> when that person wants to use "/cgi-bin/" in their own scripts.

hmmm sorry but I am not sure exactly what you mean here... if he/she
doesn't feel the benefits from the beginning than i don't think that
he/she will feel them at a later stage...

> > > 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.
> >
> > Still not wearing my apache maintainer hat, i never allow webmasters or
> > web contents managers to install directly their own cgi. Specially in big
> > environments where more than one person has rw access to the web contents.
> > Thinking of systems like Contribute or shared maintainance.
>
> That's your choice.  It should be your choice.  Right now, it's not your
> choice or my choice.  That's my point.

It is my choise and still is. I don't see how it cannot be my choise (of
course speaking as a user/admin and not as DD).

> I wish more people were as thurough as you.  Being thurough, however, does
> not mean making no changes or correcting problems.

Of course i make changes, i correct problems (or atleast try :-)) but
right now I am not convinced of the benefits of such change compared to
amount of work that needs to be done and that's why i am not stepping
forward to implement it.

> I guess I'm missing something because I don't see what the big effort is.
>
>  - The amount of effort necessary within Apache is small.

true.

>  - The amount of effort within any given package is small, perhaps even tiny.

stil they are 115 pkgs that will have a RC bug because not policy
complaint, risk is to see some of them removed for a transition and not
due to a real usability issue. Like it was said apache will have to
conflict with the ones actually in the system to ensure that all of them
will perform the transition correctly. dpkg can't even handle that
situation.

> The benefit is a system where admins have the ability to give webmasters
> access to their traditional /cgi-bin/ location without being interferred
> with by system packages.

it might even be more comfortable for webmaster and i don't think i have
many doubts about it, but i also consider the fact that it can be a
security issue having the scripts in that location in the filesystem, as
it was poitned out already none of the other implementation do so. The
scripts will get www-data:www-data ownership and not root as it is now
that ensure a readonly view of the cgi from the web server...

Fabio

-- 
Our mission: make IPv6 the default IP protocol
"We are on a mission from God" - Elwood Blues

http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp00004.html



Reply to: