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

[Bob Proulx]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-maint/attachments/20120411/e14e5c44/attachment.pgp>