Re: Re: [RFC] PECL binary creation and distribution

Thomas V.V. Cox said: > Umm, yeah better so. This way we could unbloat the PEAR package. I also > have the idea to create a peardev command, and move there the commands > not used by non-developers (package, cvstag, etc). So, what about having > sepparate packages: PEAR, PEAR-Dev, PECL-Dev. > > I could isolate the build stuff from the PEAR package and create for you > a preliminary PECL-Dev package for hacking. For the records, I'd preffer > to have the same command for building packages, both PEAR and PECL. A single tool is probably less hassle for developers to remember, so I agree with you there. As for the name, I don't really care what these things are called, so I leave it to the better judgement of whoever is doing the work :) > Nowadays, if you do a "pear rpmbuild foo" it will just generate a > foo.spec file. What I meant was that it could directly create the rpm > with the command "pecl-package -t rpm foo" and generate just the spec > with "pecl-package -t rpm --only-native-package-info-file foo" (feel > free to choose a shorter param name ;). The same for msi for example. something like this: pecl-package -t rpm --rpm-spec-only foo '--rpm-' options would be specific to the rpm build (of course). Likewise we would have '--msi-' options for the msi build etc. > My idea with the BUILDINFO.txt file, was when you get a problem > compiling an extension, you could read that file and try to adapt your > system to the libs the original developer used. Ahh yes. > > An important thing that Sara mentioned was licensing - if the package is not > > licensed under the PHP license, we should probably have some kind of > > annoying thing that displays the license just prior to installation. > > Np. Give to me the texts and the cases when you need to display them and > I'll take care on adding them. That needs someone to read the major licenses and see what the requirements are. Basically, if its the PHP license, we needn't do anything more. For BSD style licenses with advertisement clauses, we should probably display the required advertisement (this should probably have an entry in the package.xml). For the GPL style licenses, we should probably display a couple of lines that inform the user of their rights to the source code, and the worlds rights to their source when they use it ;) > > So, what would be nice would be to expand your idea above so that the > > package.xml can contain references to the source and each generated binary > > package. This info would create a native pear .tgz containing all these > > things. The author would upload that file, and the server would split it > > into a source package and a bunch of binary arch-specific packages. > > > > It probably won't end up working exactly like this, but thats the general > > idea. > > IMO is a bad idea to relay in a external site out of the pecl site. I'd > strongly recommend to the originally author to upload bin packages to > the pecl web. > > In a short time I'd create the new "pear publish" command, for > submitting packages to the web. This way you can automate this task easily. One of the key things that will make PECL successful is to make it *the* definitive place to find out about all the PHP extensions out there. I know that pear has a slightly different philosophy here, but just take a look around at the PHP extensions out there - a lot of them are hosted elsewhere. One of the reasons is the lack of awareness of PECL, but there other reasons why someone might not want to put their binaries in PECL - one of those is that commercial extensions might not want their binaries downloaded from an external (from their point of view) site. Personally, I don't think commercial extensions should be excluded from our listings - they should, in fact, be encouraged, because it is commercial interest that ultimately keeps people employed in php related jobs :-). I'd like PECL to be something like a cross between freshmeat and what we have now in PEAR, but focused on PHP extensions only. How about a compromize - when a package is stored on an external site, why not do something like this: -------------------------- # pear install acme-enterprise-foo acme-enterprise-foo is not stored in the central PECL repository. You can download it from <Author/Manufacturer Name> by typing: # pear install --redirect-external acme-enterprise-foo Remember to contact <Author/Manufacturer Name> if you experience problems with the package, as it is not maintained by the general PECL community. -------------------------- Any other suggestions? > > For example, if the system is rpm based, and there is an rpm for the package > > available, and the package is currently uninstalled, or is installed as an > > rpm for a previous version of the package, download and upgrade to the new > > rpm. > > I don't really like this idea, but it's up to you :-). I'd preffer to > default the installation of a pecl extension to bin. Perhaps a > "preffered bin type" setting would make sense). User cases: Defaulting to binary on unix scares me a little ;) > c:> pear install peclbar > No binary package for Windows i386. In order to install this extension > you need to build it from sources. Install the PECL-Dev package (pear > install PECL-Dev) and issue the command "pecl-package peclbar" (you'll > need a compiler and blah blah). Its a bit more difficult than that unfortunately :/ I have some ideas for the win32 build that might solve this, but really lack the time to make it work - it can wait for a while anyway. > Linux: > $ pear install peclfoo > Downloading: peclfoo-linux-i386-2.3.tgz > Install: ok > > or: > > $ pear install -t rpm peclfoo > Downloading: peclfoo-linux-i386-2.3.rpm > Running: rpm -Uvh peclfoo-linux-i386-2.3.rpm > Install: ok > > or: > > $ pear config-set preffered-bin-type rpm > $ pear install peclfoo > Downloading: peclfoo-linux-i386-2.3.rpm > Running: rpm -Uvh peclfoo-linux-i386-2.3.rpm > Install: ok OK, but what about when they want to upgrade? What if there is (for whatever reason) no rpm available for the upgrade? Or perhaps they choose a beta to be built from source ? The installer should be smart enough to know if an rpm version is installed and handle it correctly, or at least give the user instructions on how to handle it manually. Maybe I'm thinking too hard ;) In general, what you've said is good - if we can set these defaults appropriately at the time the pear/pecl infrastructure is installed, then it will probably work well enough for most people. This would be during ./configure time for php. ./configure --enable-preferred-package-type=rpm and have sensible defaults for when the option is omitted. > As I said I don't like the idea of relaying in external sites. There is > already a "Package Home Page" link see an example of an external hosted > package: > http://pear.php.net/package-info.php?package=PhpDocumentor To me, the packages appear to be hosted in pear. Is this not the case? --Wez.