[php-maint] [PATCH] New way to handle extensions

[Steve Langasek]

On Wed, May 30, 2007 at 06:53:05PM -0500, Raphael wrote:
> Hello Steve,

> First of all I would like to ask you to CC me on message replies as
> I'm not in the list (I found the message in the list's archive).

Well, it would be nice if you were using a mail client that supported
setting reasonable values for Mail-Followup-To.

> >Yes, the main problem I have with the proposal to turn the conf.d symlinks
> >into directories in one swoop is that it leaves a gap where a user can have
> >the new version of php installed with an old version of an extension
> >package, and either the extension won't be available to the engine or
> >removing the extension package will leave behind a symlink that won't be
> >cleaned even on purge.
> For this I'm quoting my original message:

> >And finally (I hope I'm not missing anything ;-) ), I also added a
> >per-extension postrm script template that causes all the symbolic
> >links to be removed, preventing all those php5 warnings about missing
> >extensions.
> That postrm script takes care of removing all the symbolic links that
> could exist. Of course this action is only performed when the package
> is being removed/purged and not when it is upgraded (in order to keep
> the extension enabled after upgrading to a new version).

That doesn't help the problem I've described, which is where the new version
of the extension package has *not been installed*.

Forcing the upgrade of the extension packages through versioned conflicts is
not an acceptable solution, because apt cannot guarantee graceful handling
of that scenario (the more such versioned conflicts there are, the worse the
etch->lenny upgrade path will become for the distro as a whole).

The two remaining options are to completely rearrange the directories at the
same time (heavy on the scripting, heavy on the risk of errors), or timing
it to coincide with a PHP ABI change so that we can rely on Depends instead
of Conflicts to keep things in sync (piece of cake, we already have the
initial implementation ;), but leaves the timeline in upstream's hands).

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon at debian.org                                   http://www.debian.org/