Debian Bug report logs - #458436
php-pear doesn't warn when modules are upgradeable

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Josip Rodin <joy@debbugs.entuzijast.net>

To: submit@bugs.debian.org

Subject: php-pear doesn't warn when modules are upgradeable

Date: Mon, 31 Dec 2007 11:46:15 +0100

Package: php-pear

Hi,

Upon a sarge->etch upgrade, nothing upgraded the PHP modules, which can
break user scripts. 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.

-- 
     2. That which causes joy or happiness.

Message #10 received at 458436@bugs.debian.org (full text, mbox, reply):

From: Raphael <atomo64@gmail.com>

To: control@bugs.debian.org, 458436@bugs.debian.org

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

Date: Mon, 31 Dec 2007 22:39:42 +0000

severity 458436 wishlist
thanks

Since the PEAR packages provided by de Debian package are
updated/upgraded this is not a bug but a feature request.
Your suggestion on using debconf shouldn't be followed because debconf
shouldn't be used for those kind of things, NEWS.Debian should be used
instead.

Sincerely,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

Say NO to Microsoft Office broken standard.
See http://www.noooxml.org/petition

Message #17 received at 458436@bugs.debian.org (full text, mbox, reply):

From: Josip Rodin <joy@debbugs.entuzijast.net>

To: 458436@bugs.debian.org

Cc: control@bugs.debian.org

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

Date: Fri, 21 Mar 2008 23:00:51 +0100

severity 458436 normal
thanks

Hi,

> severity 458436 wishlist
> thanks
> 
> Since the PEAR packages provided by de Debian package are
> updated/upgraded this is not a bug but a feature request.
> Your suggestion on using debconf shouldn't be followed because debconf
> shouldn't be used for those kind of things, NEWS.Debian should be used
> instead.

First off, please use the right address when you wish to talk to submitters,
your message never reached me because it was sent to the bug address only.

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

I also don't agree with using NEWS.Debian, for two reasons - firstly,
php-pear would have to depend on apt-listchanges (which shows the file),
and secondly it doesn't make sense to couple this with news items, because
each item has to be written, only to be shown once, which means that
users who skip it in the first run are never again alerted to the likely
problems. That's why a generic check and a prompt would make more sense
than a news item.

-- 
     2. That which causes joy or happiness.

Message #24 received at 458436@bugs.debian.org (full text, mbox, reply):

From: Ondřej Surý <ondrej@debian.org>

To: Josip Rodin <joy@debbugs.entuzijast.net>, 458436@bugs.debian.org

Cc: control@bugs.debian.org

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

Date: Mon, 9 Apr 2012 13:08:40 +0200

tags 458436 +wontfix
severity 458436 wishlist
thank you

On Fri, Mar 21, 2008 at 23:00, Josip Rodin <joy@debbugs.entuzijast.net> wrote:
> severity 458436 normal
> thanks
>
> Hi,
>
>> severity 458436 wishlist
>> thanks
>>
>> Since the PEAR packages provided by de Debian package are
>> updated/upgraded this is not a bug but a feature request.
>> Your suggestion on using debconf shouldn't be followed because debconf
>> shouldn't be used for those kind of things, NEWS.Debian should be used
>> instead.
>
> First off, please use the right address when you wish to talk to submitters,
> your message never reached me because it was sent to the bug address only.
>
> 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.

Thus I am here with Raphael on a wishlisting this bug. PEAR was not really
made to integrate well packaged (/usr) and external (/usr/local) packages, so
it's very hard to solve this.

This said we would certainly welcome a patch which would allow us to manage
packaged and non-packaged PEAR package separately, but I think this is something
which needs to be done upstream.

O.
-- 
Ondřej Surý <ondrej@sury.org>

Message #33 received at 458436@bugs.debian.org (full text, mbox, reply):

From: Josip Rodin <joy@debbugs.entuzijast.net>

To: Ondřej Surý <ondrej@debian.org>

Cc: 458436@bugs.debian.org

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

Date: Mon, 9 Apr 2012 20:36:06 +0200

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.

Message #36 received at 458436@bugs.debian.org (full text, mbox, reply):

From: Bob Proulx <bob@proulx.com>

To: Josip Rodin <joy@debbugs.entuzijast.net>, 458436@bugs.debian.org

Cc: Ondřej Surý <ondrej@debian.org>

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

Date: Mon, 9 Apr 2012 14:06:13 -0600

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

Message #41 received at 458436@bugs.debian.org (full text, mbox, reply):

From: Josip Rodin <joy@debbugs.entuzijast.net>

To: Bob Proulx <bob@proulx.com>

Cc: 458436@bugs.debian.org, Ondřej Surý <ondrej@debian.org>

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

Date: Tue, 10 Apr 2012 09:33:20 +0200

On Mon, Apr 09, 2012 at 02:06:13PM -0600, Bob Proulx wrote:
> > 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.

Oh for crying out loud, you are arguing against something that I never
actually argued for. My main point has always been that the package has the
responsibility to make a good faith effort to help the user once the package
is already installed and is being upgraded, just like it helped the user get
it running in the first place. I am not arguing against the whole notion of
having these tools, that sentence above was simply a demonstration of how
asinine the other line of reasoning has gotten.

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

It's a new feature in the packaging department, but not in the software
itself - the code for checking the versions that need to be upgraded
practically already exists inside the p* upgrade-all commands.

It just has to be simplified a little bit to get it to merely indicate
the status rather than do the whole upgrade action. Then the maintainer
script can run that and display a message if the status is problematic.

Heck, for all the time spent three people have now spent arguing against
straw men and pissing off the good-faith bug report submitter by way of
haggling over bug severities, someone could have just checked if it already
exists or done it themselves.

-- 
     2. That which causes joy or happiness.

Message #44 received at 458436@bugs.debian.org (full text, mbox, reply):

From: Bob Proulx <bob@proulx.com>

To: Josip Rodin <joy@debbugs.entuzijast.net>, 458436@bugs.debian.org

Cc: Ondřej Surý <ondrej@debian.org>

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

Date: Wed, 11 Apr 2012 13:23:03 -0600

[Message part 1 (text/plain, inline)]

Josip Rodin wrote:
> Bob Proulx wrote:
> > > 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.
> 
> Oh for crying out loud, you are arguing against something that I never
> actually argued for. My main point has always been that the package has the
> responsibility to make a good faith effort to help the user once the package
> is already installed and is being upgraded, just like it helped the user get
> it running in the first place. I am not arguing against the whole notion of
> having these tools, that sentence above was simply a demonstration of how
> asinine the other line of reasoning has gotten.

And that is also exactly why I wrote what I wrote, to show that it was
an absurb direction of reasoning.  I knew you were not serious about
removing the pear utility.  Although actually you opened the door for
that direction when you said "it may even warrant a request to remove
such software from Debian for being harmful".  Remember that
turn-about is fair play.  I was using the same logic you were using.
I understood you were using it as a logical premise showing an
absurdity.  And that was exactly the same as I used it too.  Same
thing.

> > > 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.
> 
> It's a new feature in the packaging department, but not in the software
> itself - the code for checking the versions that need to be upgraded
> practically already exists inside the p* upgrade-all commands.

Practically exists is not the same as does exist.  Also sometimes
features seem reasonable before being tried but then in practice prove
to be trouble.  Life is subtle that way.

> It just has to be simplified a little bit to get it to merely indicate
> the status rather than do the whole upgrade action. Then the maintainer
> script can run that and display a message if the status is problematic.

That seems reasonable.  I could even see that during an upgrade that
other such useful new behavior could happen.  However doing too much
there is a can of worms.  Anything that would normally happen by the
package manager would probably already be happening by the package
manager.  If there was a Debian package for those pear modules then
there would have been no reason to install them using pear.  It is
really a backdoor to enable things that are not handled by full Debian
packages.  But being unhandled means that the local user admin really
needs to manage the problem themselves.  Because I really think that
effort to manage locally installed pear modules should be used to
improve Debian php packaging to avoid the need for locally installed
pear modules at the start.  To me that makes the most sense.

> Heck, for all the time spent three people have now spent arguing
> against straw men and pissing off the good-faith bug report
> submitter by way of haggling over bug severities, someone could have
> just checked if it already exists or done it themselves.

I was only reacting to the ping-pong war of bug severity that was
happening in the bug log.  We haven't really discussed the technical
merits of the new feature yet.  It is a shame things got distracted.

One of my concerns over the feature is that I haven't seen anything
similar implemented in any of the other languages which have similar
tools.  Perl, Python, Ruby all have their own packaging, some in
better shape than others.  I know that someone always needs to be
first and it could be PHP's pear.  But when different groups are all
doing similar things for different reasons then the concensus behavior
tends to be a fairly good indication that it is good behavior.
Breaking new trail can be difficult when development resources are
tight.

Bob

[signature.asc (application/pgp-signature, inline)]

Message #49 received at 458436@bugs.debian.org (full text, mbox, reply):

From: Josip Rodin <joy@debbugs.entuzijast.net>

To: Bob Proulx <bob@proulx.com>

Cc: 458436@bugs.debian.org, Ondřej Surý <ondrej@debian.org>

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

Date: Thu, 12 Apr 2012 09:24:57 +0200

On Wed, Apr 11, 2012 at 01:23:03PM -0600, Bob Proulx wrote:
> It is really a backdoor to enable things that are not handled by full
> Debian packages. But being unhandled means that the local user admin
> really needs to manage the problem themselves.

Well, I think that if we have a facility to detect the fact that this
upgrade is breaking local user admin's stuff, the immediate priority is to
help them with that, because otherwise we get in the situation where they
can say "the Debian upgrade broke stuff on this machine", and they aren't
wrong.

In fact, this can be used as an opportunity to tell the user "oh, we see you
have the PECL module 'radius' - you can prevent this message in the future
by installing the equivalent 'php5-radius' Debian package and stop worrying
about the ABI".

> One of my concerns over the feature is that I haven't seen anything
> similar implemented in any of the other languages which have similar
> tools.

IIRC there's the persistent discussion with people who think Debian packages
separate from PECL/CPAN/whatever are worse than the original.

This kind of an ABI error detection and messaging would not prevent those
kinds of concerns, but it would certainly alleviate them because we wouldn't
force our packages on the users. We would simply combine the tools from both
parties to inform users something that is important for them. That seems
pretty fail-safe.

-- 
     2. That which causes joy or happiness.

Send a report that this bug log contains spam.