Re: PHP application packaging policy/best practice?

[Pierre Habouzit]

> On Wed, Jan 12, 2005 at 10:16:43AM +0100, Pierre Habouzit wrote:
> > Le Mer 12 Janvier 2005 01:31, Matthew Palmer a ?crit :
> > > So you patch libfile2.php to require_once 'mylib/libfile1.php'
> > > instead of just 'libfile1.php'.
> >
> > oh and btw, the suggestion I did is better (IMHO) :
> >
> > replace require_once 'libfile.php'; with
> >
> > require dirname(__FILE__).'/'.'libfile1.php';
> >
> > because you are robust to _any_ mess done by the user with the
> > include_path (for a zero cost). You even not assume that
> > /usr/share/php is in the include_path.
>
> But it has two giant downsides:
>
> 1) It's ugly as all hell; and
>
> 2) Once people start getting into that habit, they forget all about
> other libraries, and where they might be, and start complaining
> bitterly and/or bundling other peoples' libraries into their
> libraries, which creates a mess.
>
> There's also the issue of how to get to the library in the first
> place from your application -- you then either need to hard-code the
> path somewhere in your app (which, if you do, I *will* beat you with
> a stick) or you're back to needing the include_path, which means that
> all of your dirname() magic isn't needed anyway.
>
> Oh, another useful tidbit -- file namespaces are useful.
> library/libfile1.php isn't very likely to conflict with another
> library/libfile1.php that someone wants to install, whereas
> libfile1.php could very well conflict.


well I agree it's not _that_ perfect. It's only that from a packager POV 
I find it more safe.

I've looked at PEAR's ways. and it does not use such mechanism. only the 
namespace trick. Well, I think it's the coder choice then ...
-- 
·O·  Pierre Habouzit
··O
OOOhttp://www.madism.org


pgpRMMMUug9tJ.pgp
Description: PGP signature

Re: PHP application packaging policy/best practice?

[Matthew Palmer]

[No Cc please, as per list policy]

On Wed, Jan 12, 2005 at 10:16:43AM +0100, Pierre Habouzit wrote:
> Le Mer 12 Janvier 2005 01:31, Matthew Palmer a ?crit :
> > So you patch libfile2.php to require_once 'mylib/libfile1.php'
> > instead of just 'libfile1.php'.
> 
> oh and btw, the suggestion I did is better (IMHO) :
> 
> replace require_once 'libfile.php'; with
> 
> require dirname(__FILE__).'/'.'libfile1.php';
> 
> because you are robust to _any_ mess done by the user with the 
> include_path (for a zero cost). You even not assume that /usr/share/php 
> is in the include_path.

But it has two giant downsides:

1) It's ugly as all hell; and

2) Once people start getting into that habit, they forget all about other
libraries, and where they might be, and start complaining bitterly and/or
bundling other peoples' libraries into their libraries, which creates a
mess.

There's also the issue of how to get to the library in the first place from
your application -- you then either need to hard-code the path somewhere in
your app (which, if you do, I *will* beat you with a stick) or you're back
to needing the include_path, which means that all of your dirname() magic
isn't needed anyway.

Oh, another useful tidbit -- file namespaces are useful. 
library/libfile1.php isn't very likely to conflict with another
library/libfile1.php that someone wants to install, whereas libfile1.php
could very well conflict.

- Matt


signature.asc
Description: Digital signature

Re: PHP application packaging policy/best practice?

[Pierre Habouzit]

Le Mer 12 Janvier 2005 10:50, Kees Leune a écrit :
> On Wed, 12 Jan 2005 10:16:43 +0100, Pierre Habouzit
>
> <[EMAIL PROTECTED]> wrote:
> > Le Mer 12 Janvier 2005 01:31, Matthew Palmer a écrit :
> > > So you patch libfile2.php to require_once 'mylib/libfile1.php'
> > > instead of just 'libfile1.php'.
> >
> > oh and btw, the suggestion I did is better (IMHO) :
> >
> > replace require_once 'libfile.php'; with
> >
> > require dirname(__FILE__).'/'.'libfile1.php';
>
> So far, I have preferred to use files which include
> @ETCDIR@/package/package.cfg. In package.cfg, I define PHPDIR,
> LIBDIR, DATADIR using autotools. That way, after autoconfiguring, all
> PHP scripts have lines like

this indeed work for _apps_.
but I assume you don't want to have a config file per library !
and for those, some __FILE__ magic is really the best you can do.

It's used (e.g.) by smarty. and since the only file you should include 
while using smarty is /usr/share/php/smarty/libs/Smarty.class.php (I 
didn't really understood _why_ it's in libs/ ...), smarty has a 

define('SMARTY_DIR', dirname(__FILE__));

on the top of it.
and all the others files of the library use that magic.

the thing is, for smarty, you allways include Smarty.class.php.
but for more general libs, where there is more include files, and there 
is no preferred include for the programmer, you have to put 
dirname(__FILE__) everywhere.

-- 
·O·  Pierre Habouzit
··O
OOOhttp://www.madism.org


pgpRrWA7fRjwu.pgp
Description: PGP signature

Re: PHP application packaging policy/best practice?

[Kees Leune]

On Wed, 12 Jan 2005 10:16:43 +0100, Pierre Habouzit
<[EMAIL PROTECTED]> wrote:
> Le Mer 12 Janvier 2005 01:31, Matthew Palmer a écrit :
> > So you patch libfile2.php to require_once 'mylib/libfile1.php'
> > instead of just 'libfile1.php'.
> 
> oh and btw, the suggestion I did is better (IMHO) :
> 
> replace require_once 'libfile.php'; with
> 
> require dirname(__FILE__).'/'.'libfile1.php';

So far, I have preferred to use files which include
@ETCDIR@/package/package.cfg. In package.cfg, I define PHPDIR, LIBDIR,
DATADIR using autotools. That way, after autoconfiguring, all PHP
scripts have lines like

require_once '/etc/appname/appname.cfg';
require_once LIBDIR.'/dbwrapper.plib';
require_once LIBDIR.'/lib1.plib';
etc.

and /etc/appname/appname.cfg contains data like

define('LIBDIR', '/usr/share/appname/lib');
define('PHPDIR','/usr/share/appname/php'); 
define('DATADIR','/usr/lib/appname');

Unlike the C community, PHP developers cannot simply assume that
include files will be in our path, since that would require an
override / settings-update for each application. The other suggestion
so create a branch under /usr/share/php/appname is also a good one;
however that might lead to name conflicts as pointed out earlier.

-Kees
-- 
Kees Leune <[EMAIL PROTECTED]>

Re: PHP application packaging policy/best practice?

[Matthew Palmer]

On Wed, Jan 12, 2005 at 10:13:05AM +0100, Pierre Habouzit wrote:
> Le Mer 12 Janvier 2005 01:31, Matthew Palmer a ?crit :
> > [No Cc needed, as per list policy]
> >
> > On Tue, Jan 11, 2005 at 11:47:42PM +0100, Pierre Habouzit wrote:
> > > > it's _quite_ true that you don't need to play with include_path.
> > > > your library has to know it's installed
> > > > into /usr/share/php/ and either :
> > > >  * use some __FILE__ magic in its requires/includes
> > > >  * already use requires on /*php files
> > > >
> > > > And I assume a lots of intern libraries are do not know how to do
> > > > that. even some that ARE packaged into
> > > > /usr/share/php/
> > >
> > > what a mess.
> > > new try :
> > >
> > > It's only half-true that putting a lib into
> > > /usr/share/php/ is fine. the lib has to be able to manage
> > > such a thing, and it's a requirement for a lib put into
> > > /usr/share/php/ to be able to live there, without having
> > > to change anything in the include_path
> > >
> > > what I meant is that :
> > >
> > > libfile1.php live in /usr/share/php/mylib
> > >
> > > if libfile2.php has a :
> > >
> > > require 'libfile1.php'; anywhere, then it's not valid to package
> > > that lib in /usr/share/php/mylib, because libfile2.php
> > > NEEDS /usr/share/php/mylib to be in the include_path.
> >
> > So you patch libfile2.php to require_once 'mylib/libfile1.php'
> > instead of just 'libfile1.php'.  We've learnt to do this with C
> > include files, why can't people work out the same thing for PHP? 
> > It's probably because of PHP's history as an easy, quick-hack
> > language, that a lot of people with very little idea of even the
> > basics of writing software have made an awful lot of really bad
> > decisions...
> 
> sure, but in C, you find the problem really quick : one compilation and 
> you know if pathes are OK.
> 
> in php, you cannot know ... you have to be really more careful.

I'm sure you'll get user feedback quickly enough... and a quick grep and
scan usually picks up most of the problems.

- Matt


signature.asc
Description: Digital signature

Re: PHP application packaging policy/best practice?

[Pierre Habouzit]

Le Mer 12 Janvier 2005 01:31, Matthew Palmer a écrit :
> So you patch libfile2.php to require_once 'mylib/libfile1.php'
> instead of just 'libfile1.php'.

oh and btw, the suggestion I did is better (IMHO) :

replace require_once 'libfile.php'; with

require dirname(__FILE__).'/'.'libfile1.php';

because you are robust to _any_ mess done by the user with the 
include_path (for a zero cost). You even not assume that /usr/share/php 
is in the include_path.
-- 
·O·  Pierre Habouzit
··O
OOOhttp://www.madism.org


pgpHcHPqykJsy.pgp
Description: PGP signature

Re: PHP application packaging policy/best practice?

[Pierre Habouzit]

Le Mer 12 Janvier 2005 01:31, Matthew Palmer a écrit :
> [No Cc needed, as per list policy]
>
> On Tue, Jan 11, 2005 at 11:47:42PM +0100, Pierre Habouzit wrote:
> > > it's _quite_ true that you don't need to play with include_path.
> > > your library has to know it's installed
> > > into /usr/share/php/ and either :
> > >  * use some __FILE__ magic in its requires/includes
> > >  * already use requires on /*php files
> > >
> > > And I assume a lots of intern libraries are do not know how to do
> > > that. even some that ARE packaged into
> > > /usr/share/php/
> >
> > what a mess.
> > new try :
> >
> > It's only half-true that putting a lib into
> > /usr/share/php/ is fine. the lib has to be able to manage
> > such a thing, and it's a requirement for a lib put into
> > /usr/share/php/ to be able to live there, without having
> > to change anything in the include_path
> >
> > what I meant is that :
> >
> > libfile1.php live in /usr/share/php/mylib
> >
> > if libfile2.php has a :
> >
> > require 'libfile1.php'; anywhere, then it's not valid to package
> > that lib in /usr/share/php/mylib, because libfile2.php
> > NEEDS /usr/share/php/mylib to be in the include_path.
>
> So you patch libfile2.php to require_once 'mylib/libfile1.php'
> instead of just 'libfile1.php'.  We've learnt to do this with C
> include files, why can't people work out the same thing for PHP? 
> It's probably because of PHP's history as an easy, quick-hack
> language, that a lot of people with very little idea of even the
> basics of writing software have made an awful lot of really bad
> decisions...

sure, but in C, you find the problem really quick : one compilation and 
you know if pathes are OK.

in php, you cannot know ... you have to be really more careful.

> > I hope this was more understandable that the previous post
>
> It is a bit easier, so I've replied to this one instead of your
> first.

yeah, sorry, english is not my mother tongue, and after midnight, it's 
too difficult for me ;D
-- 
·O·  Pierre Habouzit
··O
OOOhttp://www.madism.org


pgpajwMMykEfD.pgp
Description: PGP signature

Re: PHP application packaging policy/best practice?

[Gustavo Noronha Silva]

Em Ter, 2005-01-11 Ãs 23:18 +0100, Pierre Habouzit escreveu:
> The fact is, that I have php skills/knowledges, mysql skills/knowledges, 
> but I do not know perl enough, nor python, nor pgsql at all, and it's 
> hard to pretend knowing how to write such a policy. And it appears to 
> me that gathering the 3p-people (perl/python/php) is really a vain 
> hope...

Begin with what you have, post it to this list and let people more
knowlegeable on the other technologies help where you're missing stuff.

Might work.

Thanks,

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
 Debian:   *  

Re: PHP application packaging policy/best practice?

[Matthew Palmer]

[No Cc needed, as per list policy]

On Tue, Jan 11, 2005 at 11:47:42PM +0100, Pierre Habouzit wrote:
> > it's _quite_ true that you don't need to play with include_path.
> > your library has to know it's installed
> > into /usr/share/php/ and either :
> >  * use some __FILE__ magic in its requires/includes
> >  * already use requires on /*php files
> >
> > And I assume a lots of intern libraries are do not know how to do
> > that. even some that ARE packaged into
> > /usr/share/php/
> 
> what a mess.
> new try :
> 
> It's only half-true that putting a lib into /usr/share/php/ is 
> fine. the lib has to be able to manage such a thing, and it's a 
> requirement for a lib put into /usr/share/php/ to be able to 
> live there, without having to change anything in the include_path
> 
> what I meant is that :
> 
> libfile1.php live in /usr/share/php/mylib
> 
> if libfile2.php has a :
> 
> require 'libfile1.php'; anywhere, then it's not valid to package that 
> lib in /usr/share/php/mylib, because libfile2.php 
> NEEDS /usr/share/php/mylib to be in the include_path.

So you patch libfile2.php to require_once 'mylib/libfile1.php' instead of
just 'libfile1.php'.  We've learnt to do this with C include files, why
can't people work out the same thing for PHP?  It's probably because of
PHP's history as an easy, quick-hack language, that a lot of people with
very little idea of even the basics of writing software have made an awful
lot of really bad decisions...

> I hope this was more understandable that the previous post

It is a bit easier, so I've replied to this one instead of your first.

- Matt


signature.asc
Description: Digital signature

Re: PHP application packaging policy/best practice?

[Paul Hampson]

On Tue, Jan 11, 2005 at 05:36:22PM -0200, Henrique de Moraes Holschuh wrote:
> On Tue, 11 Jan 2005, Paul Hampson wrote:
> > Someone, sometime wrote: (Sorry, lost the attribution at some point)
> > > Some people have pointed out that other PHP programs go to /usr/share
> > > as well. Just to complement: Perl modules also get installed to
> > > /usr/share if they are not architecture-specific. Python seems not to
> > > be that way, as its standard sys.path does not include /usr/share/*. 

> > On the other hand, python drops .pyc and .pyo files into the same
> > directory as the .py file at python install-time. I'd hazard a guess
> > that it can't find the .pyc and .pyo files if they're in a different
> > place than the .py file they come from.

> The bytecode is platform-independent, isn't it?  That means it also belongs
> to /usr/share.  OTOH, if .pyo is object code that is platform-dependent,
> then that means all that python stuff needs to be moved to /usr/lib, if
> python cannot be told to stop byte-compiling stuff under /usr/share.

My PowerPC Debian/Testing machine:
tbble:/usr/lib/python2.3$ md5sum filecmp.py*
87f6fca826c9ae5ce919b7b5c0374eaf  filecmp.py
9f1c4ed5de3263b262f794bb39c737fb  filecmp.pyc
9f1c4ed5de3263b262f794bb39c737fb  filecmp.pyo

tbble:/usr/lib/python2.3$ dpkg -l python2.3
ii  python2.32.3.4-13

My i386 Debian/Testing machine:
tbble:/usr/lib/python2.3$ md5sum filecmp.py*
87f6fca826c9ae5ce919b7b5c0374eaf  filecmp.py
fd27e21da14a763132a94e6074e2d186  filecmp.pyc
fd27e21da14a763132a94e6074e2d186  filecmp.pyo

tbble:/usr/lib/python2.3$ dpkg -l python2.3
ii  python2.32.3.4-13

On the other hand, my i386 Debian/Unstable machines:
tbble:/usr/lib/python2.3$ md5sum filecmp.py*
87f6fca826c9ae5ce919b7b5c0374eaf  filecmp.py
a1e61e03c0b25aab7ea5d8d9bea9a02f  filecmp.pyc
a1e61e03c0b25aab7ea5d8d9bea9a02f  filecmp.pyo

tbble:/usr/lib/python2.3$ dpkg -l python2.3
ii  python2.32.3.4-19

So I reckon it _is_ platform dependant.
In fact, given it's regeneratable data, maybe /var/lib/python2.3
would make sense?

Maybe it'd be more useful if I actually learnt to program in
Python. ^_^

-- 
---
Paul "TBBle" Hampson, MCSE
7th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


signature.asc
Description: Digital signature

Re: PHP application packaging policy/best practice?

[Pierre Habouzit]

> it's _quite_ true that you don't need to play with include_path.
> your library has to know it's installed
> into /usr/share/php/ and either :
>  * use some __FILE__ magic in its requires/includes
>  * already use requires on /*php files
>
> And I assume a lots of intern libraries are do not know how to do
> that. even some that ARE packaged into
> /usr/share/php/

what a mess.
new try :

It's only half-true that putting a lib into /usr/share/php/ is 
fine. the lib has to be able to manage such a thing, and it's a 
requirement for a lib put into /usr/share/php/ to be able to 
live there, without having to change anything in the include_path


what I meant is that :



libfile1.php live in /usr/share/php/mylib

if libfile2.php has a :

require 'libfile1.php'; anywhere, then it's not valid to package that 
lib in /usr/share/php/mylib, because libfile2.php 
NEEDS /usr/share/php/mylib to be in the include_path.


So packagers will have to patch such things with :

require dirname(__FILE__).'/'.'libfile1.php';

in order to make it /usr/share/php/--compliant


I hope this was more understandable that the previous post

-- 
·O·  Pierre Habouzit
··O
OOOhttp://www.madism.org


pgpwLgAexh0QS.pgp
Description: PGP signature

Re: PHP application packaging policy/best practice?

[Pierre Habouzit]

> > /usr/share/appname/php
>
> I go with /usr/share/appname/www to signify that is the web-root of
> my install.  Some (redhat-infected people, I guess) use
> appname/htdocs.
>
> > /usr/share/appname/lib
>
> That'd work, or if you're interested in making it a more useful
> library, you could put it in /usr/share/php/,
> where everyone can easily use it (with the added bonus that then you
> don't have to f**k with the include_path in all your apps or php.ini
> to make your library easily includable...)
>
> > /var/lib/appname
>
> That's where my datafiles go.  /var/lib/phpwiki being the primary
> offender.


you were too quick for mee.

one comment though, for /usr/share/php/ :

it's _quite_ true that you don't need to play with include_path.
your library has to know it's installed 
into /usr/share/php/ and either :
 * use some __FILE__ magic in its requires/includes
 * already use requires on /*php files

And I assume a lots of intern libraries are do not know how to do that. 
even some that ARE packaged into /usr/share/php/

IMHO, the ability to be used with only /usr/share/php in the 
include_path is sth you MUST have before putting anything in a subdir 
of /usr/share/php


for the rest I do agree 100% with you :)
-- 
·O·  Pierre Habouzit
··O
OOOhttp://www.madism.org


pgpK1TOiCfsyH.pgp
Description: PGP signature

Re: PHP application packaging policy/best practice?

[Matthew Palmer]

On Tue, Jan 11, 2005 at 11:04:55PM +0100, Kees Leune wrote:
> On Tue, 11 Jan 2005 21:20:03 +0100, Pierre Habouzit
> <[EMAIL PROTECTED]> wrote:
> > IMHO, web apps should be installed in /usr/share/*appname*/
> 
> Agree; it seems that most of the responses boil down to that. The next
> question then is; what do you do with the tree under
> /usr/share/appname? I need .php files (files which are accessible by
> the PHP interpreter), .plib files (my own extensions; php files meant
> to be included; not served by apache), and possibly datafiles which
> are peristent over sessions. Right now, I am leaning to using
> 
> /usr/share/appname/php

I go with /usr/share/appname/www to signify that is the web-root of my
install.  Some (redhat-infected people, I guess) use appname/htdocs.

> /usr/share/appname/lib

That'd work, or if you're interested in making it a more useful library, you
could put it in /usr/share/php/, where everyone can
easily use it (with the added bonus that then you don't have to f**k with
the include_path in all your apps or php.ini to make your library easily
includable...)

> /var/lib/appname

That's where my datafiles go.  /var/lib/phpwiki being the primary offender.

- Matt


signature.asc
Description: Digital signature

Re: PHP application packaging policy/best practice?

[Kees Leune]

Hi,

On Tue, 11 Jan 2005 21:20:03 +0100, Pierre Habouzit
<[EMAIL PROTECTED]> wrote:
> 
> as a php web app packager, I should say that the policy is a real mess,
> since there is no policy (and I really hope to become a DD soon, in
> order to work on one with other interested people).

Sign me up. I'm somewhere around DAM report. 

> IMHO, web apps should be installed in /usr/share/*appname*/

Agree; it seems that most of the responses boil down to that. The next
question then is; what do you do with the tree under
/usr/share/appname? I need .php files (files which are accessible by
the PHP interpreter), .plib files (my own extensions; php files meant
to be included; not served by apache), and possibly datafiles which
are peristent over sessions. Right now, I am leaning to using

/usr/share/appname/php
/usr/share/appname/lib
/var/lib/appname

-Kees
-- 
Kees Leune <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: PHP application packaging policy/best practice?

[Pierre Habouzit]

Le Mar 11 Janvier 2005 23:10, Henrique de Moraes Holschuh a écrit :
> On Tue, 11 Jan 2005, Pierre Habouzit wrote:
> > as a php web app packager, I should say that the policy is a real
> > mess, since there is no policy (and I really hope to become a DD
> > soon, in order to work on one with other interested people).
>
> You don't have to. In fact, you should try your best to work in such
> stuff BEFORE applying to become a DD, because that will probably make
> your final aproval that much easier (all other things being equal).

in fact I'm already waiting for that approval.

and the other point is that I've not found any place where people want 
to talk about web apps packaging.

a place not too crowded (debian-devel is really not the place).

I would be really really happy if a web based app and related list could 
be created. but I thought I needed to be DD to ask sth like that.

The fact is, that I have php skills/knowledges, mysql skills/knowledges, 
but I do not know perl enough, nor python, nor pgsql at all, and it's 
hard to pretend knowing how to write such a policy. And it appears to 
me that gathering the 3p-people (perl/python/php) is really a vain 
hope...

But any proof I'm wrong is welcome !
-- 
·O·  Pierre Habouzit
··O
OOOhttp://www.madism.org


pgpMSSeIgoKI2.pgp
Description: PGP signature

Re: PHP application packaging policy/best practice?

[Henrique de Moraes Holschuh]

On Tue, 11 Jan 2005, Pierre Habouzit wrote:
> as a php web app packager, I should say that the policy is a real mess, 
> since there is no policy (and I really hope to become a DD soon, in 
> order to work on one with other interested people).

You don't have to. In fact, you should try your best to work in such stuff
BEFORE applying to become a DD, because that will probably make your final
aproval that much easier (all other things being equal).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: PHP application packaging policy/best practice?

[Matthew Palmer]

On Tue, Jan 11, 2005 at 09:20:03PM +0100, Pierre Habouzit wrote:
> as a php web app packager, I should say that the policy is a real mess, 
> since there is no policy (and I really hope to become a DD soon, in 
> order to work on one with other interested people).

There's no need to be wearing your DD badge to help make a policy on
webapps.  Just get in there and do it -- something sensible needs to be
worked out.

- Matt


signature.asc
Description: Digital signature

Re: PHP application packaging policy/best practice?

[Pierre Habouzit]

> That's not enough a reason to go with lib/ in Debian IMHO.  Have a
> look on share/, and you will find that pratically everything
> arch-independent goes in there.  php itself does this.
>
> Another hint that Debian doesn't make much of a distinction between
> executables and data is the lack of libexec/
>
> --
>   "One disk to rule them all, One disk to find them. One disk to
> bring them all and in the darkness grind them. In the Land of Redmond
> where the shadows lie." -- The Silicon Valley Tarot
>   Henrique Holschuh

the thing is I think users may want to share php web apps over the 
network. and /usr/lib is definetely not the place you should put sth 
you want to share over a network. /usr/share is meant for that.

moreover, php files are not 100% executables. they even do not have 
their x bits on (nobody uses the mod_cgi anymore for php, do you ?)

things taht are in /usr/lib are :
 - shared libraries (that php files are not)
 - some executables that the normal user do not have to run himself but
   that the app internally uses (command launched by wrappers, auth
   scripts, whatever you want)

the only exception to that rule, AFAIK, is python (as already pointed 
out in this thread)



as a php web app packager, I should say that the policy is a real mess, 
since there is no policy (and I really hope to become a DD soon, in 
order to work on one with other interested people).

IMHO, web apps should be installed in /usr/share/*appname*/

and if your app uses/provides some libraries that othere apps could use, 
you have to put them into /usr/share/php/*appname*/, 
since /usr/share/php is in the include_path by default.


if your package conflicts with a PEAR one .. well, too bad ;p (when I 
told you that the lacking of a policy was a real mess ...)
-- 
·O·  Pierre Habouzit
··O
OOOhttp://www.madism.org


pgp0HpjeEh5T7.pgp
Description: PGP signature

Re: PHP application packaging policy/best practice?

[Henrique de Moraes Holschuh]

On Tue, 11 Jan 2005, Paul Hampson wrote:
> > Some people have pointed out that other PHP programs go to /usr/share
> > as well. Just to complement: Perl modules also get installed to
> > /usr/share if they are not architecture-specific. Python seems not to
> > be that way, as its standard sys.path does not include /usr/share/*. 
> 
> On the other hand, python drops .pyc and .pyo files into the same
> directory as the .py file at python install-time. I'd hazard a guess
> that it can't find the .pyc and .pyo files if they're in a different
> place than the .py file they come from.

The bytecode is platform-independent, isn't it?  That means it also belongs
to /usr/share.  OTOH, if .pyo is object code that is platform-dependent,
then that means all that python stuff needs to be moved to /usr/lib, if
python cannot be told to stop byte-compiling stuff under /usr/share.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: PHP application packaging policy/best practice?

[Paul Hampson]

On Mon, Jan 10, 2005 at 01:07:36PM -0600, Gunnar Wolf wrote:
> Kees Leune dijo [Fri, Jan 07, 2005 at 02:19:18PM +0100]:
> > Hi,
> > 
> > I am preparing an ITP for a PHP application that is currently under
> > development at my place of employment. While thinking about packaging
> > it, I was wondering if there is any PHP application policy or best
> > practice. I am now leaning to a setup as follows:
> > (...)
> > Note that I chose /usr/lib over /usr/share because according to the
> > FHS, /usr/share is meant for "all read-only architecture independent
> > data files". Although PHP files are read-only and architecture
> > indepedent, I consider them as programs.
> 
> Some people have pointed out that other PHP programs go to /usr/share
> as well. Just to complement: Perl modules also get installed to
> /usr/share if they are not architecture-specific. Python seems not to
> be that way, as its standard sys.path does not include /usr/share/*. 

On the other hand, python drops .pyc and .pyo files into the same
directory as the .py file at python install-time. I'd hazard a guess
that it can't find the .pyc and .pyo files if they're in a different
place than the .py file they come from.

If it can, then I suggest the directory layout's wrong.  /usr/share is
for package-managed things that can be shared between architectures, as
I understand it.  This overrides /usr/lib/ being for non-user-executable
binaries, but does not seem to override /usr/bin and /usr/sbin being for
user-executable binaries, shareable or not.

(I suspect it _ought_ to, and  if the shareable binaries were big enough
and /usr/share/bin was likely to appear in the default path, then noise
would be made to make this happen "in the near future")

-- 
---
Paul "TBBle" Hampson, MCSE
7th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


signature.asc
Description: Digital signature

Re: PHP application packaging policy/best practice?

[Gunnar Wolf]

Kees Leune dijo [Fri, Jan 07, 2005 at 02:19:18PM +0100]:
> Hi,
> 
> I am preparing an ITP for a PHP application that is currently under
> development at my place of employment. While thinking about packaging
> it, I was wondering if there is any PHP application policy or best
> practice. I am now leaning to a setup as follows:
> (...)
> Note that I chose /usr/lib over /usr/share because according to the
> FHS, /usr/share is meant for "all read-only architecture independent
> data files". Although PHP files are read-only and architecture
> indepedent, I consider them as programs.

Some people have pointed out that other PHP programs go to /usr/share
as well. Just to complement: Perl modules also get installed to
/usr/share if they are not architecture-specific. Python seems not to
be that way, as its standard sys.path does not include /usr/share/*. 

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: PHP application packaging policy/best practice?

[Jérôme Warnier]

Le samedi 08 janvier 2005 à 18:32 -0500, sean finney a écrit :
> hi there,
> 
> On Sat, Jan 08, 2005 at 03:05:15PM +0100, Jérôme Warnier wrote:
> > > Any thoughts?
> > I collected some interesting Debian packaging Web Applications policy
> > drafts some time ago:
> > http://glasnost.beeznest.org/articles/184
> 
> to throw another link out:
> 
> http://people.debian.org/~seanius/policy/
You obviously didn't take a look at my page. :-P
This link is the first one on my list.

> right now, there's a heck of a lot more work done on the
> database-specific aspect of web-applications, though it's my
> intention to eventually cover the whole gamut.  
> 
> my two recommendations are to use /usr/share/$pkg (or a subdir) for
> the application pages, and don't modify configuration files of other
> packages.  
> 
> 
>   sean
> 

Re: PHP application packaging policy/best practice?

[sean finney]

hi there,

On Sat, Jan 08, 2005 at 03:05:15PM +0100, Jérôme Warnier wrote:
> > Any thoughts?
> I collected some interesting Debian packaging Web Applications policy
> drafts some time ago:
> http://glasnost.beeznest.org/articles/184

to throw another link out:

http://people.debian.org/~seanius/policy/

right now, there's a heck of a lot more work done on the
database-specific aspect of web-applications, though it's my
intention to eventually cover the whole gamut.  

my two recommendations are to use /usr/share/$pkg (or a subdir) for
the application pages, and don't modify configuration files of other
packages.  


sean

-- 


signature.asc
Description: Digital signature

Re: PHP application packaging policy/best practice?

[Jérôme Warnier]

Le vendredi 07 janvier 2005 à 14:19 +0100, Kees Leune a écrit :
> Hi,
> 
> I am preparing an ITP for a PHP application that is currently under
> development at my place of employment. While thinking about packaging
> it, I was wondering if there is any PHP application policy or best
> practice. I am now leaning to a setup as follows:
> 
> /usr/lib/appname/php  Publicly loadable PHP pages
> /usr/lib/appname/libIncluded PHP libraries (not reachable via httpd)
> /var/lib/appname Persistant data
> /etc/appname/appname.cfg Configuration
> /etc/appname/apache.conf   Apache configuration (symlink from
> /etc/apache/conf.d)
> 
> Note that I chose /usr/lib over /usr/share because according to the
> FHS, /usr/share is meant for "all read-only architecture independent
> data files". Although PHP files are read-only and architecture
> indepedent, I consider them as programs.
> 
> Any thoughts?
I collected some interesting Debian packaging Web Applications policy
drafts some time ago:
http://glasnost.beeznest.org/articles/184

I accept any comments, especially improvements of course.

> -Kees

Re: PHP application packaging policy/best practice?

[Henrique de Moraes Holschuh]

On Fri, 07 Jan 2005, Kees Leune wrote:
> /usr/lib/appname/php  Publicly loadable PHP pages
> /usr/lib/appname/libIncluded PHP libraries (not reachable via httpd)
> /var/lib/appname Persistant data
> /etc/appname/appname.cfg Configuration
> /etc/appname/apache.conf   Apache configuration (symlink from
> /etc/apache/conf.d)
> 
> Note that I chose /usr/lib over /usr/share because according to the
> FHS, /usr/share is meant for "all read-only architecture independent
> data files". Although PHP files are read-only and architecture
> indepedent, I consider them as programs.

That's not enough a reason to go with lib/ in Debian IMHO.  Have a look on
share/, and you will find that pratically everything arch-independent goes
in there.  php itself does this.

Another hint that Debian doesn't make much of a distinction between
executables and data is the lack of libexec/

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: PHP application packaging policy/best practice?

[Roberto Sanchez]

Quoting Kees Leune <[EMAIL PROTECTED]>:

> Hi,
> 
> I am preparing an ITP for a PHP application that is currently under
> development at my place of employment. While thinking about packaging
> it, I was wondering if there is any PHP application policy or best
> practice. I am now leaning to a setup as follows:
> 
> /usr/lib/appname/php  Publicly loadable PHP pages
> /usr/lib/appname/libIncluded PHP libraries (not reachable via
> httpd)
> /var/lib/appname Persistant data
> /etc/appname/appname.cfg Configuration
> /etc/appname/apache.conf   Apache configuration (symlink from
> /etc/apache/conf.d)
> 
> Note that I chose /usr/lib over /usr/share because according to the
> FHS, /usr/share is meant for "all read-only architecture independent
> data files". Although PHP files are read-only and architecture
> indepedent, I consider them as programs.
> 
> Any thoughts?

Horde and its associated applications install to /usr/share, if that makes
any difference to you.

-Roberto Sanchez


This message was sent using IMP, the Internet Messaging Program.

PHP application packaging policy/best practice?

[Kees Leune]

Hi,

I am preparing an ITP for a PHP application that is currently under
development at my place of employment. While thinking about packaging
it, I was wondering if there is any PHP application policy or best
practice. I am now leaning to a setup as follows:

/usr/lib/appname/php  Publicly loadable PHP pages
/usr/lib/appname/libIncluded PHP libraries (not reachable via httpd)
/var/lib/appname Persistant data
/etc/appname/appname.cfg Configuration
/etc/appname/apache.conf   Apache configuration (symlink from
/etc/apache/conf.d)

Note that I chose /usr/lib over /usr/share because according to the
FHS, /usr/share is meant for "all read-only architecture independent
data files". Although PHP files are read-only and architecture
indepedent, I consider them as programs.

Any thoughts?

-Kees
-- 
Kees Leune <[EMAIL PROTECTED]>