nspluginwrapper 1.0, coming soon.
Hi all,
I apologise for not getting nspluginwrapper 1.0 into Debian yet. The main
problem is with "npconfig" (which users call /usr/bin/nspluginwrapper). The
Debian package patches the binary to install symbolic links to each
individual plugin directory for each browser, and changes to the npconfig
tool mean that the patch isn't applying cleanly to the source.
What will happen over the next few days (and few weeks) is this:
Stage 1. Getting 1.0 in.
The next version of nspluginwrapper, 1.0-1 will be a mostly vanilla update
to 0.9.91.5-2. The patch has been reworked to work with the new npconfig
version and will exhibit the same behaviour as the previous version. This
will be a mostly safe update.
I've added debconf support to ask users if they would like plugin loaders
updated on package update. This is mostly for convenience, but you can turn
it off if you like.
Stage 2. Slimming down npconfig, and adding subrevisions.
npconfig is okay, but it does too much to take work away from the user. As a
result, it only installs to directories it knows about, and will not install
a wrapper stub to an arbitrary location. I've been working on stripping out
most of this functionality in order to turn it into a bare plugin creation
tool.
Whilst I'm making changes to this, I'm adding subrevisions to the wrapper
version string. You may notice if you run 'nspluginwrapper -l' that you see:
/home/user/.mozilla/plugins/npwrapper.libflashplayer.so
Original plugin: /home/user/.mozilla/plugins32/libflashplayer.so
Wrapper version string: 0.9.91.5
Since we often add stability patches (e.g. the g_thread initialisation) to
Debian revisions, the version string doesn't accurately represent the "real"
version of the wrapper loader stub. This will change to look something like:
Wrapper version string: 1.0-1
This will mean that on package updates, we can identify what loaders require
updating using npconfig to incorporate changes to the package source, and
avoid leaving old binaries sitting around.
Since npconfig will be stripped down, a new tool will be added to manage the
installation of the binaries and symlinks around the system. This is likely
to be written in shell script, and it will call npconfig to do the dirty
work.
Stage 3. Splitting the package into two (or three, or four as the case may be).
When I initially packaged nspluginwrapper, I intended to roll it out for
both amd64 and ia64 architectures. I failed. ia64 misses some important
parts, like an i386 compiler to make the runtime loader.
Splitting the package into two will create three new packages:
nspluginwrapper: a metapackage depending on the two packages for your system.
nspluginwrapper-wrapper: the browser plugin and npconfig tools.
nspluginwrapper-runtime-i386-slim: a "slim" runtime for i386 on amd64.
The name of the last package isn't finalised yet. It is described as a
"slim" runtime, because Debian amd64 contains everything we already need
to build i386 binaries, and has native libraries as well. As a result, the
package will contain the runtime loader binaries and not much else. But it
will be needed to run i386 binaries on amd64 systems.
nspluginwrapper will become a noarch package (I hope) and
nspluginwrapper-wrapper should be devoid of enough architecture specific
code to build on any architecture and provide the foundations for supporting
running i386 (or other) plugins on any architecture.
What happens then? Well, the intention is to create a
"make-nspluginwrapper-runtime" tool which will create a runtime environment
for the required architecture (mostly i386, since we're mostly dealing with
i386 plugins for which we don't have the source). This will pack up enough
libraries and the runtime loader and you should then be able to run your
favourite plugin on non-amd64 architectures. I have an ARM version of
flashplayer 9 to test with, and a PowerPC machine that I hope to get the
i386 flashplayer to run on. But this shouldn't concern most vanilla amd64
users.
This part (the make-nspluginwrapper-runtime part), however, is a tricky one,
and not without problems. I need to work out the cleanest way of packing up
non-native binaries for other architectures, and compile binaries for other
architectures. I've been playing with scratchbox2 and hope this will
suffice.
In any case, that's the plan of action!
rob.
--
rob andrews :: pgp 0xd6c3e484 :: rob@choralone.org
Reply to: