[php-maint] 13 php pear module ready in the Git to be sponsored

[Thomas Goirand]

Hi,

Sorry that it took me some time to reply to this one. I'm back to my
Debian packaging work after a dive into my companies 2009 accounting
(hell, I hate doing that spreasheet work...).

sean finney wrote:
> hi thomas,
> 
> some quick comments:
>> git clone http://git.debian.org/git-http/pkg-php/php-crypt-cbc.git
> 
> Initialized empty Git repository in /home/sean/debian/php-crypt-cbc/.git/
> fatal: '/pkg-php/php-crypt-cbc.git' does not appear to be a git repository
> fatal: The remote end hung up unexpectedly

It's because the URL was wrong. The following works:

git clone http://git.debian.org/git/pkg-php/php-crypt-cbc.git

> first, yes at least I do have a strong
> preference for the existing build methods and tools (branch naming,
> practices, and tools).  doing things differently won't necessarily block
> your packages from being accepted into debian, but it will definitely
> serve as a deterrent for me (and i'd assume others) to help out.  what
> were your objections to the existing tools/methods?

The fact that I use a specific target ontop of what is used shouldn't
prevent you from using the standard tools. However, I removed it from
the git. The package now uses debian-sid and upstream-sid branches as it
was advised to me in another post.

> secondly, the packages do not build in a policy compliant manner, which
> is a more serious issue in terms of gaining acceptance into the archive.
> debian policy is pretty specific about which targets are mandatory in a
> source package's debian/rules file.  for example, debian/rules install
> does not create the installation tree, and debian/rules binary does not
> produce the deb.  as a general rule i wouldn't add to or modify the
> debian/rules interface (someone preparing an NMU should not have to
> know anything about a particular source package's "special" build
> methods), but the required targets are a hard requirement.

That was a remaining of the very old package that I didn't spot. This is
corrected. I had a look to various php-* packages that I maintain, and I
think it's the only one that had this issue (though I will check again
each package one by one and write back to this list when done).

Can you please consider the package again, so at least one is done?

Thanks for your time on the package review,

Thomas

P.S: Seems lintian still checks against policy 3.8.3. Should I still
update my Standard-Version: field to the new number?