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

[Raphael]

On 30/05/07, Steve Langasek <vorlon at debian.org> wrote:
> 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.
I've never really liked mail clients, I use gmail's web interface.

>
> > >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*.
A simple prerm that makes sure the package isn't going to be removed
and then renamed the symlink to extension.ini.upgrade and then a
postinst that checks for the existence of such file and renames it
back to extension.ini
All this functionality can easily be added to the two scripts I wrote,
reducing the prerm and postinst to about four lines of code.

>
> 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).
Is the above solution enough for this?

>
> 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).
What exactly does "PHP ABI" means? I have no idea what is it about.
>
> --
> 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/
>


-- 
Atomo64 - Raphael

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