[pkg-php-pear] [Pkg-php-pear] On PEAR packaging

Gunnar Wrobel wrobel at horde.org
Thu Jul 28 05:42:35 UTC 2011 

Hi!

Quoting Mathieu Parent <math.parent at gmail.com>:

> Hello,
>
> 2011/7/24 Gunnar Wrobel <wrobel at horde.org>:
>> Quoting Mathieu Parent <math.parent at gmail.com>:
>>
>>> Hello,
>>>
>>> 2011/7/24 Gunnar Wrobel <wrobel at horde.org>:
>>> [...]
>>>>>
>>>>> Yes, but this is still good to know that all packages build (libs,
>>>>> apps, bundles), except:
>>>>> - those without package.xml
>>>>> - those with invalid package.xml (hermes, kolab, koward)
>>>>
>>>> True. And I assume there are packages which do not cleanly build if
>>>> pulled
>>>> from pear.horde.org at the moment.
>>>
>>> How do you build from pear.horde.org (I use --allow-remote but there
>>> is no download)?
>>
>> "--allow-remote" is the right thing to use. I'm not 100% certain I
>> understand your question. To build from the remote PEAR server it is better
>> to avoid executing the command in the git repo as some package names -
>> basically the applications like "imp" and so on - match local paths in the
>> git repo. In that case the source is being preferred. But if you are outside
>> the repo "--allow-remote" should enable the download. And for the real
>> packaging the remote package is of course the only reasonable base.
>
> I was running the tool from the git repo. That is the reason... A
> --force-remote option would be a bonus.

Hm, I have to think about it. I already didn't like the --allow-remote  
switch :) The ability to use remote packages is still rather fresh and  
my first attempt in adding support for this on the command line was  
probably not the best one. It might make sense to avoid the  
"autodetection" completely and rather use a notation that clearly  
indicates the package source.

>
>> My comment was just aimed at the packages that we fixed in source these days
>> but that did see no updated release on pear.horde.org yet. I assume you need
>> to build those from source right now until the next version of those get
>> released. If we need a better picture of the timeline to be expected then I
>> can harass Jan about it.
>
> Yes.

Most of the framework packages have been released yesterday and I  
assume the applications will follow today. So most should actually be  
fine and the list of packages that still have problems should be  
small. I would suggest that you just indicate where you would still  
need fix in a release and either I or Jan will release it. For  
framework packages this should be no problem at all as we also release  
those for small fixes. Application might take a bit longer. But I  
don't expect this to be a significant blocker.

>
>
>>>>>
>>>>> I have started to test, all packages installs correctly (appart from
>>>>> Horde_Thrift, see #10376) when installing fake packages
>>>>> "php-crypt-blowfish", "php-net-dns2" and "php-phpunit" (using equivs).
>>>>>
>>>>> The interface works but I fail to connect to an IMAP server due to the
>>>>> missing Crypt_Blowfish library. This is P1 on my TODO-list.
>>>>
>>>> Great, this sounds good.
>>>
>>> This is now done, I will upload it soon.
>
> php-crypt-blowfish is now in unstable:
> http://packages.qa.debian.org/p/php-crypt-blowfish.html
>
> This was the last important missing bit (There is still a package name
> mismatch for phpunit).
>
>>>>> Also, the generated packages don't respect FHS because the config are
>>>>> in /usr/share instead of /etc. This is P2.
>
> The config are now as wanted. See attached patch 3.

All patches pushed. P3 made me think about wether we actually want to  
keep the Debian packaging information in the components tool.

I see the following drawbacks:

  - You can't commit directly
  - We might add substantial amounts of data to the components package  
that is very specific to Debian and might not be needed by most people  
that use the components package.
  - The data may get out of sync with the actual packaging (depending  
on whether we can keep up the close collaboration and whether you use  
the tool for upgrading later as well)

On the positive side:

  - it is a good example to other packagers that could use the same facilities
  - it allows to generate source snapshot packages from git  
immediately and those would apply to a Debian based system immediately

I think it would be better to place the files into an external  
repository and replace the stuff in "data/distribute/debian" by a  
"data/distribute/README" that would link to a horde wiki page that  
details the packaging efforts for various distributions. And I think  
it makes most sense to have the "templates" repository on the Debian  
side of life. Do you agree?

>
>
>
>> I don't think there will be a generic implementation that works for all PEAR
>> packages. The way test suites are arranged can differ wildly between the
>> different packages. For Horde the test suite is always in "test" and there
>> is a file AllTests.php within that directory. This one should be executable
>> using "phpunit test/Horde/Xyz/AllTests.php". If you add a stub to your build
>> system I can look into completing it. I'm pretty certain however that there
>> will still be issues with the test suites in many packages. Mainly because
>> they are currently run in an environment that has a defined setup and we
>> didn't test many variations of this environment yet. Most of the problems
>> should be easy to fix on our side though. And I'm pretty interested in the
>> results and in getting the suites clean. I'm also the main driving force
>> behind http://ci.horde.org
>
> This add-test.diff for an test boilerplate.
>
> The problem with those test is that the dependencies are required
> during build.

True. Would there be a way to ensure this in "override_dh_auto_test"?  
Something that quickly validates that all run-time dependencies are  
present and bails out if they are not - indicating what the problem was?


> Maybe we can use an opt-in (DEB_BUILD_OPTIONS=check)
> instead of en opt-out (DEB_BUILD_OPTIONS=nocheck).

Does it make sense to support both? "nocheck" seems to be standardized  
so I would suggest to support it. But of course it does not make sense  
to try to run the tests if we only have the build dependencies  
available. Interrupting the build at that point and forcing the  
packages to use "nocheck" does not seem that appropriate either. If it  
is possible to check for the presence of the required run-time  
packages (see above) then I would suggest the following behaviour:

ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
   # Check for build time deps
   # They are missing:
     # WARN but continue
   # They exist:
     # Run the tests
endif
ifneq (,$(findstring check,$(DEB_BUILD_OPTIONS)))
   # Check for build time deps
   # They are missing:
     # EXIT
   # They exist:
     # Run the tests
endif

>
>
> <<<TODO
> General Debian TODOs:
> ---------------------
> [x] config in /etc
> [ ] Create ITPs
> [ ] debian/copyright

I don't think I will add COPYRIGHT/LICENSE files to the framework  
packages right now. I have been slightly confused by how we do  
Copyright notices in the code for some time actually so I sent a more  
generic request to the dev@ mailing list to ask for some feedback on  
how we want to handle this in the future.

> [ ] Test
> [ ] Upload to experimental
> [ ] translations in /usr/share/locale
> [ ] Run tests during build
>
> Dependencies:
> -------------
> Depends: php5-cli php-pear php5
>  included: php5-ldap
>  ok:       php5-memcache
>  ok:       php-db php-http-request php-net-sieve php-auth-sas
>            php-date php-text-wiki php-text-wiki php-net-smtp
>  done:     php-crypt-blowfish
>  todo:     php-phpunit (phpunit #nnnnnn)
>
>
> Recommends:
>  included: php5-mysql php5-curl php5-gd php5-imap
>  ok:       php5-sasl php5-idn php5-geoip
>  wip:      php5-apc (php-apc #635295) php5-ssh2 (libssh2-php #635296)
>  todo:     php5-lzf php5-eaccelerator php5-xdiff php5-http php5-pam
>            php5-mysqli (in php5-mysql) php5-pdo (in php5-common)
>  ok:       php-net-imap php-net-socket php-mdb2 php-text-captcha  
> php-text-figlet
>            php-services-weather
>  todo:     php-net-dns2 php-xml-svg php-console-getopt
> php-console-table php-file-find
>            php-soaprpc php-date-holidays php-text-wiki-bbcode
> php-text-wiki-cowiki
>            php-text-wiki-creole php-text-wiki-doku php-text-wiki-mediawiki
>            php-text-wiki-tiki
>
> Not related to Horde:
> ---------------------
> [ ] PECL or extension packages incorrectly named (should be named php5-*):
> usr/lib/php5/20090626/apc.so                            php/php-apc
> usr/lib/php5/20090626/ssh2.so                           devel/libssh2-php
> usr/lib/php5/20090626/libpuzzle.so
> interpreters/libpuzzle-php
> usr/lib/php5/20090626/imlib.so                          php/php-imlib
> (no package.xml; has both .php and ext)
> usr/lib/php5/20090626/php_wikidiff2.so
> php/php-wikidiff2 (no package.xml)
> usr/lib/php5/20090626/IcePHP.so
> php/php-zeroc-ice (no package.xml)
> usr/lib/php5/20090626/gv.so                             php/libgv-php5
> usr/lib/php5/20090626/hdate.so                          php/libhdate-php
> usr/lib/php5/20090626/expect.so                         web/libexpect-php5
> TODO>>>
>
> Next work for me is:
> <?php
> foreach($pkg in $pkgs) {
>    submit_itp($pkg);
>    write_copyright_file($pkg);
>   upload($pkg, "experimental");
> }
>
>

Still a lot of work ahead but it looks good :)

Cheers,

Gunnar

>
> Cheers
>
> --
> Mathieu

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de

More information about the pkg-php-pear mailing list