[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

[Olivier Berger]

Thomas Goirand <zigo at debian.org> writes:

> On 06/14/2012 04:52 PM, Olivier Berger wrote:
>> Cause it was easier for a start. And cause I wanted to go fast instead
>> of waiting for your advice on where to store it, but that can be changed
>> easily.
>> 
>> FYI, I also pushed my work to github so as to mark it as a clone of the
>> upstream repo, in the hope it can be useful wrt git-buildpackage
>> (security patches tracking and likes).
>
> Please don't store Debian stuff on Github. Feel free to make it a backup
> of what's on Alioth (using a Git hook for example, there's a recent
> thread about this in debian-devel at l.d.o, and it seems easy to do).

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.

> IMO, we are really better of using our own Debian server, rather than
> a 3rd party which does commercial operation and who doesn't open its
> source code (I mean by that that github itself is closed source).
>
> I hope you wont see me as an open source extremist when writing this. I
> just believe that Debian should stay independent from any 3rd party...

You don't need to convince me, I'm actually contributing to FusionForge,
and doing a lot of work in this area for years for these very reasons :-)

>
>>> * Why did you add some debian/{docs,examples,install} files then? If
>>> that's a PEAR package, then the package.xml will reference all of these,
>>> "pear install" called by pkg-php-tools will do the work for you.
>>>
>> 
>> That's initially what I had started, using the direct result of debpear.
>> 
>> But I didn't like the way dh_auto_install worked with pkg-php-tools :
>> docs were installed as /usr/share/doc/php-cas/CAS/... instead of
>> directly under /usr/share/doc/php-cas/, for example for the included
>> examples/ subdir which should normally be
>> /usr/share/doc/php-cas/examples/ and not
>> /usr/share/doc/php-cas/CAS/examples per policy IIRC.
>
> 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 ...

>
> Also, remember that pkg-php-tools is team maintained, and that Mathieu
> Parent (its original author) doesn't have much time to maintain it
> currently (he posted about it), so it'd be really welcome if you could
> help enhancing it. I've already sent minor patches against it, but I'm
> not so good with Perl, so help would be welcome!
>

Thanks ;)

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

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

>> Maybe that's a problem with the package.xml which I could have solved
>> with a patch, or a problem with pkg-php-tools. But I must say I'm no
>> expert in debhelper, and I find it more explicit to state what needs to
>> be installed and where using the debian/[docs|examples|install]
>> files.
>
> 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 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.).

> Anyway again, I think this should be solved by modifying pkg-php-tools,
> rather than modifying each individual PEAR package we maintain.
>

ACK.

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

>> Done already (btw, did I report I've uploaded the package to the NEW
>> queue yesterday late ? ;).
>
> Nope! Well done! :)
> I hope you'll make it for Wheezy.
>
> By the way, I had no time to handle the nusoap stuff. Do you think you
> could? Do you think we need to ask for a transition with the release
> team? Or maybe it's too late already?
>

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.

>>> * I don't believe that the apache-2.0 copyright notice you wrote in
>>> debian/copyright is enough. Shouldn't you write the full text of it?
>>>
>> 
>> I'm not sure, but that seems somehow what other packagers have done
>> already. Lintian didn't complain either.
>
> That's not what I've seen in other packages, but you may be right.
> Anyway, if you're wrong, you'll take the responsibility of it, and
> handle the ftp-masters flame! :)
>

No big deal in any case.

>>> * Why did you override_dh_auto_install ?
>>>
>> 
>> See above.
>
> I don't get it. There was an empty override_dh_auto_install. This was to
> avoid that pkg-php-tools does it? Then how the hell did you get the .reg
> in? :)
>

Uh... don't have a clue.

Would need more testing probably.

Best regards,

-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)