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

[Bob Proulx]

Josip Rodin wrote:
> Ondøej Surý wrote:
> > Josip Rodin 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.

This seems very similar to perl, perl packaging, and the use of cpan
to install perl modules into /usr/local.

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

That reads like a wishlist feature.  If that feature is implemented
for any of the other languages with a similar structure then I am
unaware of it.  For example if you use cpan to install perl modules
into /usr/local then that is outside the realm of the package manager
and those files are the responsibility of the person who put them
there.

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

Agreed.

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

Exactly.  And specifying /usr/local is exactly what you are doing when
you use cpan, er...,  pear to install php modules.

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

As soon as you type in the words "pear" instead of "apt-get" then you
are saying "I have the controls" and are taking responsibility for it.
The issue is that "pear" is not "apt-get" and the two are not
interchangable.

Perhaps this is a documentation issue?  A problem is that upstream
projects often prefer and recommend these pseudo-package tools making
it harder to modify all of the needed documentation everywhere.

> 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

This isn't specific to php and is a problem with perl, python, ruby
and other languages too.  You have fallen into a trap thinking that
upstream will create some random pseudo-package method and that it
will always be able to interoperate with apt.  That just ain't so.  In
most cases being able to make those interoperate would be impossible.

At worst I think going down your line of reasoning would force that
Debian must disable and remove (as you said) every upstream
pseudo-package tool.  For example cpan must be removed because its
operation is outside the scope of apt's package operation.  And yet if
that were done it would annoy users who expect that to be able to
work.  There would be the opposite bug report asking to have that
feature enabled.  These two views are diametrically opposed and in
conflict with each other.  Only one can work.  Most people prefer to
have upstream tools such as cpan and pear available and accept that
they operate outside the realm of the package manager.

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

Agreed.  The two methods are irreconcilable at this time.

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

At that point I think the severity is a wishlist.  It would be a new
and never before implemented feature.  It would be waiting for
contributed code that might actually do it.

Bob