[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: missing file in php-net-ipv4 in official package



Steve Langasek wrote:
> On Mon, Jul 30, 2007 at 11:04:54AM +0300, Thierry Randrianiriana wrote:
> 
>> I'm the maintainer of php-net-ipv4, normally the package provides a
>> file IPv4.php
>> in /usr/share/php/Net/ . This file is correctly installed with the
>> package built on my pc :
>> ~$ ls -l /usr/share/php/Net/
>> total 64
>> -rw-r--r-- 1 root root 14168 2007-06-12 16:34 IPv4.php
>> -rw-r--r-- 1 root root 29099 2005-08-03 08:27 SMTP.php
>> -rw-r--r-- 1 root root 15357 2005-08-03 08:27 Socket.php
> 
>> But with the package built on debian servers:
> 
> The package that's in the Debian archive was not built on a Debian server,
> it was built wherever your sponsor built it.
> 
> Because it's an arch: all package, this package would not have been built on
> any Debian buildds, which also means we have no build logs for it to show
> what went wrong.
> 
> At a minimum, I would suggest updating your package so that the build rules
> notice, and treat it as a fatal error, if key files go missing.  That won't
> directly answer the question of why the package in the archive is wrong, but
> it will make the task of tracking down the bug in your sponsor's devel
> environment a bit easier.
> 
> Cheers,

What I feel strange about is that in the original tarball, there is no
SMTP.php and Socket.php, but only IPv4.php. SMTP.php is from
php-net-smtp, and I guess that Socket.php is from php-net-socket. That
means that the package doesn't have any file packaged at all, and that
seems very strange.

When you have a look at the debian/rules, here is what you can see in
the install: part

install: build
        dh_testdir
        dh_testroot
        dh_clean -k
        dh_installdirs

        cp package.xml $(pear_pkg)/package.xml;
        $(PEAR) install -n -R debian/$(package) $(pear_pkg)/package.xml;

        rm -f debian/$(package)/usr/share/php/.filemap;
        rm -f debian/$(package)/usr/share/php/.lock;
        rm -rf debian/$(package)/usr/share/php/.channels;
        rm -rf debian/$(package)/usr/share/php/.depdblock;
        rm -rf debian/$(package)/usr/share/php/.depdb;
        rm -rf debian/$(package)/usr/share/php/docs;
        rm -rf debian/$(package)/usr/share/php/tests;
        rm -rf
debian/$(package)/usr/share/php/.registry/.channel.pecl.php.net;
        rm -rf debian/$(package)/usr/share/php/.registry/.channel.__uri;
        rm -rf debian/$(package)/tmp;

All that, when the orig.tar.gz has ONE unique file to setup, and when
this would have been enough:

	install -D -m 0644 $(PEARSRCDIR)/IPv4.php
$(DEB_DESTDIR)/usr/share/php/Net/IPv4.php

Clearly, a "template" has been used. Also, I have been said that my CDBS
package was not a so good idea because made of "black magic". But, IMHO,
what has been done here is even worth...

It seems that the intention of the maintainer was to have the file
/usr/share/php/.registry/net_ipv4.reg installed together with the
package. I didn't know that this file was needed, and that it was the
way that pear knows a given package is setup. But as long as we are
supposed to use ONLY Debian package and not "pear install", I want to
ask here if you think if that is really needed or not.

When building the package, the file IS present (I had a check with mc,
and when I install the packge, it's working correctly...), so I don't
really understand the last post. Was there a recent update in SID the
last 2 days?

The funny thing is that I did a package for this one as well, and then
when I was about to do the ITP, I saw that somebody else did it (and the
ITP was not closed, surprisingly). I know I should have done it the
opposite way (eg: do the ITP first), but that's done already and the
package was really small... If somebody wants to have a look:

git clone http://git.gplhost.com/pear.git

or just use our gitweb: http://git.gplhost.com/gitweb/

All together, now that I did about 10 pear extension Debian packages or
so, I am wondering if it was possible to create a script that would
parse the "package.xml" file to auto generate the debian/rules file the
correct way. An automated system would have many advantages. Some that
come to my mind: make Debian packages very fast, reduce the possibility
to make errors, make it possible to have updates very fast at the same
time as the one from pear.php.net, ...

Also, the package.xml has all the needed information: upstream author,
license, and list of files and where to set them up. As it's an XML
file, it's quite easy to parse.

Of course, this doesn't mean that the resulting Debian folder shouldn't
be check for consistency. This is the role of both the maintainer, and
the sponsor.

If anybody is interested about this idea and want to work with me doing
it, let me know. One of the subjects that I'd like to discuss is what
tool to use to parse the file. Maybe php itself as it can be called from
shell?

Thomas Goirand



Reply to: