Hi!
On 4:31:31 pm 08/23/05 Charles Fry <debian@frogcircus.org> wrote:
We are discussing about php policy in this list.
I think we can finish this policy and after make these changes :)
I respectfully disagree. :-)
I propose that we try to get dh-make-php (and other standard tools) to
approximate our best guess at a policy, and then modify them over time
as necessary.
Agreed.. policy should be best practice, not vice versa.
That said, I don't have the experience/understanding to respond to the
issues you raised, so I am of no practical help here. Uwe?
I have a really simplistic patch right now that creates a dh-make-php5
package, which can then be used to create php5-specific source packages for
extensions (really only looking at PECL atm; the PEAR discussion is
interesting, but somewhat unrelated). I think having a single source
package per module that can build separate binary packages (ie. source
php-{module} -> php4-{module} and php5-{module}) is a better solution
(you'd have to build the entire source twice).
Other thing,, PEAR packages that have "PHP License" cant be
packaged , because IHMO :(
Maybe I missed something here, but your reasoning is a bit vuague. One
of my PEAR packages was initially rejected for using the PHP License,
becasue it has several clauses that are specifc to PHP the language,
and make no sense when applied to a PHP program.
Using the PHP license outside of PHP isn't a great idea, granted.. I'm not
entirely clear on the implications for something like PECL, though. e.g.
is something like the Runkit extension "part of PHP"? (It is distributed
separately, yes.. then again, the API is documented in the official
manual.. seems grey to me.)
In any event, I'm interested in the technical issues more than the
licensing debate; worst case scenario is that a module couldn't exist in
Debian proper - it could certainly still be packaged :)