Re: [Gnash-dev] Help with building a XPI

[Sylvain Beucler]

Hi,

A couple comments:

> > - the suite is 'unstable' while it's a Lenny (stable) package. This
> >   blocked the upgrade for me because I give 'unstable' a lower
> >   priority in /etc/apt/preferences (hence I can hand-pick unstable
> >   packages while remaining stable for the rest). So for a stable
> >   repository it makes sense to use the 'stable' suite.
> 
>   I wouldn't consider snapshots to be stable, that'd be more for releases.

I think this field is best used to match the target Debian release,
rather than express the actual status of the package (which is usually
part of the URL, e.g. "../snapshots/..").


> > dpkg : erreur de traitement de 
> > /var/cache/apt/archives/gnash_trunk20090313_i386.deb (--unpack) :
> >  tentative de remplacement de « /usr/share/pixmaps/gnash.xpm », qui 
> > appartient aussi au paquet gnash-common
> > dpkg-deb: sous-processus paste tué par le signal (Relais brisé (pipe))
> > 
> >   (i.e. gnash.xpm is in gnash while it was in gnash-common) This isn't
> >   very important as the error disappears after relaunching apt-get .
> 
>   It should be in both.

I didn't check extensively in this particular case, but normally a
file is only part of one package.


> > I was also asking about XPI though.  IMHO distro repos are fine, but
> > are suboptimal if it's possible to provide statically-linked,
> > one-click-install binaries.
> 
>   I'd like to see this work too. :-) I guess I'll take a break from RTMP
> and MIPS hacking and make another attempt to fix xpi package building.
> Where I could use help is making sure the XPCOM support actually works,
> as the plugin needs that to find the executables. I'd actually prefer to
> not statically link the gnash executable, but as the users profile
> directory is always different, I haven't figured out a good way to
> handle that.

Any piece of documentation you would recommend? :)

Incidentally, isn't it possible to bundle gtk-gnash in the .so?

-- 
Sylvain