Heya, sorry for the delay.
On Sun, Nov 15, 2009 at 11:15:56PM +0100, sean finney wrote:
Inherently, such a proposal applies to static content, not CGI
applications. I fail to see where lay problems about unconfigured static
content.
read-only static content unpacked from packages is
hi stefano,
On Fri, Nov 13, 2009 at 10:09:20AM +0100, Stefano Zacchiroli wrote:
I understand this problem, but I think you're shooting at the wrong
target. The advanced proposal (beside the aesthetically displeasing
name) is about standardizing a default vendor document root on disk so
that
Sorry for the delay in replying to this. I've just re-read all the
disagreements with the original proposal and they all seem to be related
to this main counter-argument by Sean, hence I'll reply here.
On Mon, Nov 09, 2009 at 11:50:11PM +0100, sean finney wrote:
FWIW, I'm fine with /vendor.
On Mon, Nov 09, 2009 at 03:55:58PM -0800, Russ Allbery wrote:
sean finney sean...@debian.org writes:
something that hasn't really been brought up (i mentioned it on the
non-webapps thread in -devel already) is that this makes packages
potentially opened in an unconfigured state. unless
On Tue, Nov 10, 2009 at 09:49:10AM +0800, Paul Wise wrote:
On Tue, Nov 10, 2009 at 6:50 AM, sean finney sean...@debian.org wrote:
personally, beyond the aesthetically displeasing name, i'm really
skeptical that this will accomplish anything useful.
* most apps require extra config and
hi!
On Tue, Nov 10, 2009 at 09:29:13AM +0100, Jan Hauke Rahm wrote:
Support for multiple independent instances configured to use arbitrary
locations for data/configuration, arbitrary vhosts and arbitrary
sub-paths of those vhosts.
That means: as many files reusable by each instance as
On Tuesday 10 November 2009, sean finney wrote:
someone ought to file a wishlist bug against php5. at the very
least there could be a debconf prompt controlling the global
status of php, and i think there's a strong case for arguing that
apps shouldn't assume that it's on by default.
I
I haven't read all of the thread yet, but:
On Monday 09 November 2009, Jan Hauke Rahm wrote:
Now, I'm willing to run this, i.e. file bugs against web
servers, wait for them to be fixed, then file bugs against web
applications (if needed, I'm right now looking into a way to
make a
On Sat, Nov 07, 2009 at 03:23:22PM +0100, Jan Hauke Rahm wrote:
Full ack, and I even like /usr/share/www. It's easy to understand and
pretty unprobable that we'd have a package called www in the archive
some day needing this location.
Sorry, I have to disagree with this approach. We would
Jan Hauke Rahm j...@debian.org writes:
On Mon, Nov 09, 2009 at 03:55:58PM -0800, Russ Allbery wrote:
sean finney sean...@debian.org writes:
something that hasn't really been brought up (i mentioned it on the
non-webapps thread in -devel already) is that this makes packages
potentially opened
On Fri, Nov 06, 2009 at 06:53:32PM -0600, Manoj Srivastava wrote:
Something short, generic and distro-neutral like /app/ would be my
personal preference if I were developing a standard for my servers.
Unfortunately, going that direction as also increases the chances of
remapping a path the
On Sat, Nov 07, 2009 at 03:23:22PM +0100, Jan Hauke Rahm wrote:
1. If we have a generic location for packages to drop their
html/php/whatever files, like /var/lib/www, all web servers can keep
their DocRoot as /var/www and provide an alias for /var/lib/www, for
instance
On Sun, Nov 08, 2009 at 12:09:28AM +0900, Charles Plessy wrote:
For new packages, grouping everything in /usr/share/www sounds like a good
idea. The alias name, « vendor », I find a bit disturbing because we do not
sell anything. But picking the name will be the priviledge of the Do-o-crat
Le Mon, Nov 09, 2009 at 10:24:39AM +0100, Stefano Zacchiroli a écrit :
On Sun, Nov 08, 2009 at 12:09:28AM +0900, Charles Plessy wrote:
Still, having /usr/share/www as a document root does not prevent complex
packages to be fragmented between /usr/share, /usr/lib/cgi-bin/, /var/lib/,
On Mon, Nov 09, 2009 at 10:15:00AM +0100, Stefano Zacchiroli wrote:
On Fri, Nov 06, 2009 at 06:53:32PM -0600, Manoj Srivastava wrote:
Something short, generic and distro-neutral like /app/ would be my
personal preference if I were developing a standard for my servers.
Unfortunately,
On Mon, Nov 09, 2009 at 10:21:12AM +0100, Stefano Zacchiroli wrote:
On Sat, Nov 07, 2009 at 03:23:22PM +0100, Jan Hauke Rahm wrote:
I still see a problem with the upgrade path for existing installations.
I might be wrong but I think the most difficult cases are very custom
setups with lots
On Mon, Nov 09, 2009 at 07:04:22PM +0900, Charles Plessy wrote:
the lintian error dir-or-file-in-var-www exists for a long time, and I
believe that most packages with active maintainers have already been
split according to the FHS. What I question is whether it is worth the
effort to move the
hi guys,
On Mon, Nov 09, 2009 at 02:56:59PM +0100, Jan Hauke Rahm wrote:
To try making it a bit less ugly (and hard to type due to the moving
nature of - as others have pointed out), I just try to mediate with
/vendor/.
FWIW, I'm fine with /vendor.
personally, beyond the aesthetically
On Mon, Nov 09, 2009 at 06:15:42PM +0100, Stefano Zacchiroli wrote:
I frankly hope that with /vendor/ + /usr/lib/cgi-bin/ (which we already
have), and maybe with some symlinks under /vendor/ we will be able to
address quite a lot of issues. It would be interesting to known which
one we can't.
sean finney sean...@debian.org writes:
something that hasn't really been brought up (i mentioned it on the
non-webapps thread in -devel already) is that this makes packages
potentially opened in an unconfigured state. unless you can ensure that
the system is only running on localhost, it has
On Tue, Nov 10, 2009 at 6:50 AM, sean finney sean...@debian.org wrote:
personally, beyond the aesthetically displeasing name, i'm really
skeptical that this will accomplish anything useful.
* most apps require extra config and splitting out of stuff into other
directories for fhs compliance
On Sat, 7 Nov 2009, Jan Hauke Rahm wrote:
Caudium can and will adjust to any standard that the community agrees
upon and it can handle different directories without problem.
I really dont have that much input for how this should be done but leaving
it as it is now is worse.
Thanks for
On Thu, Nov 05, 2009 at 04:39:06PM +0100, Stefano Zacchiroli wrote:
On Thu, Nov 05, 2009 at 10:21:48AM +0100, Jan Hauke Rahm wrote:
Okay, I understand. Now, I see two ways actually to solve this.
1. If we have a generic location for packages to drop their
html/php/whatever files, like
Le Sat, Nov 07, 2009 at 03:23:22PM +0100, Jan Hauke Rahm a écrit :
I still see a problem with the upgrade path for existing installations.
I might be wrong but I think the most difficult cases are very custom
setups with lots of changes by the local admin. I'm thinking of e.g.
On Fri, Nov 06, 2009 at 06:53:32PM -0600, Manoj Srivastava wrote:
On Fri, Nov 06 2009, The Fungi wrote:
On Fri, Nov 06, 2009 at 01:11:47PM +0100, Harald Braumann wrote:
/debian/ seems to be the de facto standard for Debian archives. So I
guess it wouldn't be such a good idea to use it for
Thanks for your response, Charles!
On Sun, Nov 08, 2009 at 12:09:28AM +0900, Charles Plessy wrote:
As a maintainer of a web application, I share your worries. I never had any
user request to make it work out of the box with alternative web servers, so I
guess that my users have nothing to gain
Le Sat, Nov 07, 2009 at 04:16:54PM +, Tzafrir Cohen a écrit :
To see your locally-installed documentation, use:
http://localhost/vendor-apps/dwww
Hello Tzafrir,
native Debian applications are actually the ones which have the least benefit
from this. I like a lot doc-central,
[ adding -policy to Cc: ]
On Wed, Nov 04, 2009 at 04:08:02PM +0100, Holger Levsen wrote:
Uhm, why postpone this so long? I'd hope we could find a consensus quite
soon.
Then, we might not be able to fix _all_ web apps until squeeze, but at least
tthose few with dir-or-file-in-var-www :-)
I
Stefano Zacchiroli dijo [Wed, Nov 04, 2009 at 05:50:01PM +0100]:
Uhm, why postpone this so long? I'd hope we could find a consensus quite
soon.
Then, we might not be able to fix _all_ web apps until squeeze, but at
least
tthose few with dir-or-file-in-var-www :-)
I see it a tad
On Wed, Nov 04, 2009 at 11:03:20AM -0600, Gunnar Wolf wrote:
Stefano Zacchiroli dijo [Wed, Nov 04, 2009 at 05:50:01PM +0100]:
Uhm, why postpone this so long? I'd hope we could find a consensus quite
soon.
Then, we might not be able to fix _all_ web apps until squeeze, but at
least
On Wed, Nov 04, 2009 at 07:15:55PM +0100, Jan Hauke Rahm wrote:
I don't get it. This would of course solve the problem of FHS compliance
but apart from that it doesn't gain anything, does it?
Now, do I totally misunderstand the issue here, or are we just moving
the /var/www problem to
I'm commenting a bit between the paragraphs to sharpen my mind :)
On Wed, Nov 04, 2009 at 08:09:18PM +0100, Stefano Zacchiroli wrote:
What I was aiming to is a kind of document root which is under full
control of the package manager; hence where the sysadm cannot touch
anything by hand. That's
32 matches
Mail list logo
