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
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
> tha
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.
>
Jan Hauke Rahm writes:
> On Mon, Nov 09, 2009 at 03:55:58PM -0800, Russ Allbery wrote:
>> sean finney 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 st
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 woul
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
> > >
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
hi jan,
On Tue, Nov 10, 2009 at 09:15:43AM +0100, Jan Hauke Rahm wrote:
> Not that I'm opposing to what you're saying but... every application in
> the archive is configured during the installation process, possibly
> asking debconf questions, providing defaults etc. After the installation
> it sh
On Tue, Nov 10, 2009 at 4:29 PM, 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 possible, t
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 instanc
On Tue, Nov 10, 2009 at 09:49:10AM +0800, Paul Wise wrote:
> On Tue, Nov 10, 2009 at 6:50 AM, sean finney wrote:
>
> > personally, beyond the aesthetically displeasing name, i'm really
> > skeptical that this will accomplish anything useful.
> >
> > * most apps require extra config and splitting
On Mon, Nov 09, 2009 at 03:55:58PM -0800, Russ Allbery wrote:
> sean finney 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 ensu
On Tue, Nov 10, 2009 at 6:50 AM, sean finney 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 anyway, thus
sean finney 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 some significa
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'
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 aest
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 t
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
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.
> > > Unfortunat
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 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
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
> > >inst
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 p
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 yo
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,
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 ga
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 u
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.
> webmail.do
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 fil
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
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 /var/
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
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
[ 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 :-)
34 matches
Mail list logo
