[php-maint] Bug#458436: Bug#458436: Bug#458436: php-pear doesn't warn when modules are upgradeable

[Josip Rodin]

On Mon, Apr 09, 2012 at 01:08:40PM +0200, Ondøej Surý wrote:
> > I disagree on the wish part - the whole purpose of the pear package is to
> > get those external PEAR packages. If pear is used to put those files on
> > users' systems, it also has the responsibility to take care of them once
> > they're there. The tool itself does do that, but the package doesn't
> > properly integrate with it. If we lower the bar for package quality to
> > the level where one only has to ship the binaries and be done with it,
> > then integration of software features with package features is a "wish",
> > but it's 2008...
> 
> If you install custom packages into /usr/local/ using gcc as a compiler,
> you also don't get a warning when shared library is upgraded. That's exactly
> same situation as with PEAR package. If you install anything by hand, then
> it's your responsibility as a system administrator to get them upgraded.

Please try not to make such bogus analogies. GCC doesn't install anything
into /usr/local by default - it only does that if the user *specifies*
/usr/local as the path for some of its output. The system administrator
who runs:

	sudo apt-get install pear && sudo pear install something

...is not specifying /usr/local anywhere - they are using the main tool that
the package provided for them to accomplish the stated goal of the software.
They're not doing anything out of the ordinary.

If you're saying that the package is not responsible in any way for what
happens next, then I'd say that the package has literally led the user into
a trap there, and we've descended so much below the quality standard of
2008, it may even warrant a request to remove such software from Debian for
being harmful to its users. And it's now 2012, BTW. :P

> PEAR was not really made to integrate well packaged (/usr) and external
> (/usr/local) packages, so it's very hard to solve this.

I don't see how it's very hard to solve the original bug report, which said:

 The package should make some sort of an effort to warn that an upgrade is
 necessary, maybe have a debconf prompt that offers to run pear upgrade-all
 and pecl upgrade-all when modules with an old ABI version are detected.

ABI versions are detectable - that's the whole point of having different
versions?

I reviewed the history and noticed the inanity of the previous reply about
debconf, I forced myself to re-read the relevant part of the Policy Manual.
http://www.debian.org/doc/debian-policy/ch-binary.html says:

3.9.1 Prompting in maintainer scripts

Package maintainer scripts may prompt the user if necessary. Prompting must
be done by communicating through a program, such as debconf, which conforms
to the Debian Configuration Management Specification, version 2 or higher.
[...]
Packages should try to minimize the amount of prompting they need to do
[...]
If a package has a vitally important piece of information to pass to the
user (such as "don't run me as I am, you must edit the following
configuration files first or you risk your system emitting badly-formatted
messages"), it should display this in the config or postinst script and
prompt the user to hit return to acknowledge the message.
[...]

So the issue is whether the matter is vitally important and above the
threshold of minimum prompting. According to the standard set by the Policy
Manual above, a message such as:

	You have previously installed modules <list X, Y, Z> using pear.
	We have detected that their ABI version no longer matches the
	currently installed ABI version, so if you haven't intervened
	in some manner already, they have now stopped working.
	You must manually run pear upgrade-all and pecl upgrade-all
	to upgrade them to the current ABI version.

...is quite above that threshold IMO.

-- 
     2. That which causes joy or happiness.