Matt Here, we are not going to split all PHP extensions into its own packages (like the way done on common linux distributions). We want to split only the packages that are currently disabled by default (which causes user to manually enable it by editing their corresponding .ini file). It is a great idea to deliver a extension readme or some thing like that to talk about all the extension that we deliver and its corresponding packages
- Sriram Matt Ingenthron wrote: > Jyri Virkki wrote: >> Sriram Natarajan wrote: >> >>> Hi >>> To simplify development / deployment with php in opensolaris, we >>> deliver various additional extensions like suhosin, tcpwrap, idn, >>> xdebug etc within our PHP package (SUNWphp52u) . However, they are >>> not enabled by default. User will need to manually enable them by >>> editing the ini files. Going forward, I would like to split these >>> extensions into their own packages and installing this package will >>> automatically enable this extension. If any one thinks this is a >>> crazy idea, please let me know ? >>> >> >> In general, sounds good. Ideally we want Web Stack components to "just >> work" by installing the corresponding package(s), so your proposal is >> in line with the goal. >> > > If I may offer a counterpoint on this.... > > Part of that means working as the user is expecting to when coming > from another platform. My concern with this approach is those new to > pkg would have to grok it and how it wires in the extensions. I don't > know enough about the expereine with these extensions on other > platforms, but I'm guessing they're installed by default. > > Might it be better to include the common extensions and perhaps even > build some utility to turn them on and off? Maybe that's what the > package manager is, but that seems somewhat confusing. > > I would highly recommend some kind of "EXTENSIONS" readme file or > other comments in the appropriate .ini files to clue users in to how > to obtain other functionality in any event. > > Just my opinion.... > > - Matt
