[pkg-php-pear] dh_auto_install worked with pkg-php-tools woes - Re: Co-maintainers for phpCAS interested ? - Was: Re: Updating the packaging bits for phpCAS 1.3.1

[Thomas Goirand]

On 06/15/2012 05:07 PM, Olivier Berger wrote:
> That's what I've done : the "central" repo is on alioth (my personal one
> for the moment), and I just pushed the changes related to syncing with
> upstream's sources to github in a cloned repo of upstream's as courtesy
> to them.

Cool!

>> If you don't like the way pkg-php-tools does, then let's discuss that
>> instead! I don't really like it either, but at least we have a standard
>> for all of our PEAR packages, which is what pkg-php-tools is about.
> 
> The thing is it's the first time I used it and I don't know very much if
> that's its common behaviour or problems with php-cas' particular
> package.xml ...

It's a common behavior. I don't know the internals of pkg-php-tools much
either, but we'll have to deal with it... :)

Are you reasonably good with perl scripting? I'm not... :/

>>> /usr/share/doc/php-cas/examples/ and not
>>> /usr/share/doc/php-cas/CAS/examples per policy IIRC.
>>
>> I don't think the policy imposes you this. The later is fine, IMO. Could
>> you point to the policy manual part that does say this?
>>
> 
> http://www.debian.org/doc/debian-policy/ch-docs.html#s12.6

It's a "should", not a "must", so it's a relaxed wording (so, it's not a
policy violation to have one more folder).

> also man dh_installexamples which is what is used when overriding the
> pkg-php-tools stuff and providing a debian/examples file.

Though, I agree with you. It's just that we should keep things as made
by pkg-php-tools, IMO, and if we need, change pkg-php-tools, as we
already discussed and agree.

>> Well, again, I believe we should make all of our PEAR packages the same
>> way, and avoid multiple packaging standards.
> 
> Indeed, hence this thread I wanted to start discussing with you, to
> determine if pkg-php-tools needs to be changed (provided again that
> php-cas' package.xml isn't strange).

I believe it does. Then we could just do a simple rebuild (binary only
upload?) of existing PEAR packages to have binary packages conform to
the new "standard".

>> I don't see the trouble with having /usr/share/doc/php-cas/CAS. In any
>> ways, if you want to remove that folder, then it could be done a way
>> faster using:
>>
>> override_dh_link:
>> 	dh_link -O--buildsystem=phppear
>> 	mv debian/php-cas/usr/share/doc/php-cas/CAS/* \
>> 		debian/php-cas/usr/share/doc/php-cas
>> 	rmdir debian/php-cas/usr/share/doc/php-cas/CAS
>>
>> That's 4 lines of debian/rules that are avoiding 3 files under your
>> debian folder, plus it works even if upstream is changing stuff in his
>> package.xml.
> 
> I don't agree. I think it is better to avoid such code and just use the traditional
> debhelper way as I did : it's way better to have source package config
> files like debian/examples, debian/docs or debian/install than shell
> commands in a makefile IMHO. That's much more maintainable and
> introduces less variability (assumptions on existence of certain
> commands, bashisms, etc.).

Well, let's not discuss this, I believe both ways aren't good, and that
we should make it fully automated by pkg-php-tools. Let's try to do it
with pkg-php-tools if possible. FYI, the git repo is on alioth in:

/git/pkg-php/pkg-php-tools.git

that's the one that has the latest changes (eg: don't use the one that
is in the horde repo which should be killed).

>> I have added Mathieu Parent as Cc:, so he will be able to tell why he
>> decided to use
>> /usr/share/doc/php-<pear-package-name>/<pear-package-name> for storing
>> docs. I am suspecting this is to avoid file collision.
>>
> 
> Looking forward for more opinions.

I don't think you should wait for too long. Mathieu wrote he's busy, and
there's not a lot of people involved.

> I don't know, and franly I don't have any use for SOAP or foresee any in
> the future (I'm more and more a REST fan ;-). And since noone voiced and
> concerns... it's probably too late to start breaking apps APIs relying
> on it.

That's what I wrote to debian-release at . I think we're fine with the old
version for the moment.

Cheers,

Thomas