Ainsi parlait Vincent Danen :
> On Mon Oct 06, 2003 at 07:48:29PM +0200, Guillaume Rousse wrote:
> > > Oden.. nice to see, but you didn't install it in a good way.
> > >
> > > You have include/ exposed, which would have been fine for 0.2.3 or
> > > earlier, but the layout should really be something like:
> > >
> > > /var/www/anthill
> > >
> > > rather than /var/www/html/anthill. Then you just expose
> > > /var/www/anthill/html (ie. via an Alias or a symlink), but you keep
> > > include/, etc/, etc. unexposed and entirely unreachable for maximum
> > > security.
> >
> > There have been some discussion previously about this, see
> > http://qa.mandrakesoft.com/twiki/bin/view/Main/PackagingTask#Web_applicat
> >ions for kind of synthesis.
> >
> > The point was to use /var/www/html/%{name} for every application, and to
> > use FHS compliant location for non-web files. If you have a configuration
> > directory for anthill, it seems for me more logical to use /etc/anthill
> > for it than /var/www/anthill/etc, for instance. The same could be said
> > for include, that should rather go into /usr/share/anthill.
> >
> > > I can fix this a little later on if you like (or you can). I'm not on
> > > the cooker list anymore so you'll have to cc me.
> >
> > I'd prefer to restart this discussion on web applications policy first...
>
> Ack... this is why I don't think web apps should be rpm packaged.
And this is the reason why i think web apps installation should be discussed
first before being packaged :-)
> Can you make it even more convoluted and hard for people to use?
That's the same answer i had from java developpers when i tried to explain
them putting all depended libs and build binaries in CVS was wrong.
> Wouldn't it make more sense to have something like:
>
> /var/www/packages/%{name}
>
> that you install everything into and then add a <Directory></Directory>
> clause to httpd.conf or some other include file so we can alias, for
> example
>
> /geeklog/ /var/www/html/packages/geeklog/public_html/
>
> or
>
> /anthill/ /var/www/html/packages/anthill/html/
>
> so we don't screw around with the "normal" way of doing things?
If the normal way is plainly wrong because developpers have no clues about
system administration, for whatever reason, should we just keep it this way ?
Web apps are especially concerned because they are mostly using Perl, PHP, and
other multiplatform languages, meaning:
- some developpers come from windows world
- developpers have to take care about windows world
As for Java software, the result is to bring all the default from broken
platforms (meaning win32) to Unix world.
Think of a native, purely unix application, where the author made a wrong
installation decision. As a packager, it is yours responsability to make it
better. This can be achieved in multiple way, such as patching, using
symlink, etc... See how apache, for instance, is itself packaged whereas
standard install drop everything under a single TLD.
> You start throwing anthill/include into /usr/share/anthill and anthill/etc
> into /etc/anthill and you're going to be messing up all kinds of people
> unless you plan on rewriting the docs. This goes for every web app, not
> just anthill.
And all other applications too, where packager work is usually
underdocumented.
> Anways anthill/etc is not a configuration directory.. it has upgrade files,
> etc. The configuration is in anthill/include. So you propose to put
> anthill/include into /etc/anthill and anthill/etc into /usr/share/anthill?
I propose to avoid the windows-like habit of throwing everything under a
single directory, without ever considering if it makes sense to put README,
LICENSE and .po files there...
I don't however have definitive answers about where to put everything else,
explaining why i'm proposing to discuss it.
For configuration files, i find it more logical as a sysadmin point of view
(we are discussing client-server applications, right) to find configuration
files under /etc, rather to have to run rpm -q --docfiles to see where they
are installed. And i find more secure to install something out of web root,
instead of under web root with access denied.
> If you do stuff like that, authors and people on mailing lists will start
> people to avoid "Mandrake packaged web apps" like the plague... you've just
> made support 3x as difficult because the authors aren't going to know where
> stuff goes.
Until someone realise than using just "urpmi imp" is enough to install
everything needed in a secure manner, without useless aditional craps, etc.
Or that "urpmi bugzilla" install database, cron task, etc... automagically.
This is a general packaging problem: either you favor respect for original
software, and let users do everything at hand (slackware style), or you favor
integration and distribution coherency, and provide user a framework for
repeated tasks (Debian style). I am personaly much in favour of 2nd one,
provided we could _document_ the additonal added value, which is clearly
lacking currently :-(
> You'll also likely screw up stuff like include("../somefile"); directives
> and the like.
That's also a problem, i have to agree. That is why using symlinks is usually
less error prone IMHO.
--
You never catch on until after the test.
-- Natalie' Law of Calculus
