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 /debian. That way webapp packages don't even have to care > > > about the web server in charge, we don't need a webapps-common, we > > > just need all web servers to provide that alias (or if they can't, > > > they have to symlink it). Every webapp would be available at > > > localhost/debian/webapp. Since it's either a symlink or a conffile > > > that makes this /debian alias, it can be changed by the local > > > sysadmin without any risks and without touching our packages data. > > I only have a couple of remarks on some details: > > > > - According to FHS, /var/lib/ is for "variable state information". As we > > are talking about static HTML content, which only change upon package > > upgrade, I believe it would not be appropriate. A better place would > > probably be /usr/share/www/PACKAGE/ (maybe some FHS guru can give us > > some insights here ...) > > 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.
Fine, it seems we're done with this aspect then.
> > - Regarding the URL that would be mapped to that dir, I don't
> > particularly like /debian/ (even though I've advanced it). However the
> > alternative solutions I can come up with (e.g. /packages/) are
> > actually uglier. So I guess /debian/ can stay. Some of the -webapps
> > people can probably come up with wiser suggestions ...
>
> Manoj suggested '/vendor-apps' and I like that. It says what it should
> say and doesn't steal any probable path.
Right, but it is possibly hard to type and a bit ugly, I've
counter-proposed "/vendor/" (see my separate mail on that).
> 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.domain.tld being a virtual host with DocRoot
> /usr/share/squirrelmail. If the files there move to
> /usr/share/www/squirrelmail we break a lot of setups. So, what about
> shipping a symlink from the old location to the new one as a migration
> path? This doesn't solve the very default (e.g. users accessing
> squirrelmail via localhost/squirrelmail) but that is so easily solved
> via alias directive or symlink that I suppose a NEWS.Debian entry would
> fit best here.
> What do you say?
I think that migrations from complex setup to this new setup will stay
complex no matter what we do. Also, it is not really something we can
"standardize" upon as migrations are very specific to each involved
packages and will ultimately be dealed with by single maintainers. So
I'd refrain to propose a generic upgrade path and just describe the new
situation we want to obtain.
> 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 lintian check for it,
> e.g. package-with-section-web-but-no-files-in-canonical-docroot). But I
> don't feel like we're having a clear consensus here, do we?
Well, defining consensus is always a tricky business :), but I haven't
heard significant voices against, am I wrong? I'd personally proceed as
follow: write a draft document (even a very brief one!) which summarizes
the proposal so that people do not need to dig into the thread to follow
the evolution. Once we have it, re-post it to the relevant lists (I'd
say -devel, -policy, -webapps) and ask for comments.
Actually, your suggested MBF text can pretty much be that document. If
it were me, I'd open a DEP on that just because I fear losing track of
it, but YMMV.
> Attached is a suggestion for MBF as well as a dd-list of all relevant
> web servers (if I did my job right).
Wow, thanks!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
