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

[Mathieu Parent]

Hi,

2011/7/28 Gunnar Wrobel <wrobel at horde.org>:
[...]
> 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.

I agree.

[...]
> 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.

OK.


> 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 plan to use "components" only to bootstrap. I don't want to depend
on an almost complete horde framework to create a package.

But I also plan to give back any meaningfull change to horde (as I
have done). The only diff should be the debian/copyright and the
debian/changelog.

>
> 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?

Keeping it in "components" makes sense as it is small (which is the
case currently).

I think it won't change much, as currently one template match more
than 50 pacakges (it is generic enough).


>>> 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?

Yes, it would be possible. But I prefer a non-automatic user-driven choice.

>
>> 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

Usually, nocheck means "I don't want the check" (here is means "check
if deps are present). Also, I'm not a makefile expert, but I think
that you will run tests twice in some cases.

ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
    # do nothing
else ifeq (,$(findstring check,$(DEB_BUILD_OPTIONS)))
    # do the tests:
    ./test.php
endif

(this avoid doing the test if DEB_BUILD_OPTIONS=nocheck which match check)

>>
>> <<<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.

The copyright file is in the debian directory, it is a review of
copyright by the packager. This is not your job, but if you or others
want to help ... (see http://dep.debian.net/deps/dep5/ for the format)

[...]
> Still a lot of work ahead but it looks good :)

There is almost 50 dependencies to Horde_Core : Oh my!
About 20 more to have the main horde apps.

Ciao

-- 
Mathieu