1 |
> Guess I'm missing the point here. What I meant was to change stuff |
2 |
like |
3 |
> this: |
4 |
> |
5 |
> require_once(HOME . "/thirdparty/Smarty/Smarty.class.php"); |
6 |
> |
7 |
> to something like this: |
8 |
> |
9 |
> $include_path = ini_get('include_path'); |
10 |
> ini_set('include_path', HOME . '/thirdparty' . SEPARATOR . |
11 |
$include_path); |
12 |
> require_once('Smarty/Smarty.class.php'); |
13 |
> |
14 |
> What is the negative side of such a change? |
15 |
|
16 |
None, provided the app is 100% compatible with the version of the Smarty |
17 |
that's normally bundled with the app. As we discovered with the |
18 |
PEAR::XMLRPC issues last year, many apps were not compatible with the |
19 |
latest unbundled version of the library. |
20 |
|
21 |
> Where is the difference to C or Java? |
22 |
|
23 |
C uses ELF shared libraries, which are versioned at the library loader |
24 |
level. PHP, and Java for that matter, has no native support for |
25 |
versioning libraries. |
26 |
|
27 |
You haven't answered the question about how you will address the issue |
28 |
of versioning unbundled libraries. |
29 |
|
30 |
> The recent xpdf discussion basically touched the same issue, right? |
31 |
|
32 |
I don't recall following that discussion. |
33 |
|
34 |
> Packaging precompiled binaries into java source packages is a common |
35 |
> practice but has been effictively banned by the java herd. Sometimes |
36 |
> necessitates larger changes in the build scripts for the app but I |
37 |
guess |
38 |
> it increases maintainability in the long run. |
39 |
> |
40 |
> Where is the difference for the php libraries? |
41 |
|
42 |
The difference is one of culture. The PHP community does not have a |
43 |
culture of re-usable third party libraries yet. Hopefully that will |
44 |
improve as developers start to adopt PHP 5, but it's not there yet. |
45 |
|
46 |
How much work will it be to test PHP apps against unbundled libraries? |
47 |
How much additional QA work will be generated by faults, because our |
48 |
testing will not be thorough enough? If UPSTREAM does not adopt your |
49 |
patches, and does not support the same versions of the libraries that |
50 |
you provide unbundled, how will they react when Gentoo users report bugs |
51 |
to them that do not appear in the UPSTREAM release? |
52 |
|
53 |
How many reported security faults over the last 24 months have been down |
54 |
to faults in bundled libraries? And how does that compare to the list |
55 |
of security faults as a whole? For the problems we've dealt with over |
56 |
the last 24 months, how many security fixes would have been released |
57 |
sooner to our end-users? |
58 |
|
59 |
I'm not (yet) convinced that what you want to do has any real benefit to |
60 |
our users, or to our understaffed team. |
61 |
|
62 |
Best regards, |
63 |
Stu |
64 |
|
65 |
-- |
66 |
gentoo-web-user@g.o mailing list |