About a browser hier-like module

[Jose M Rodriguez]

El Jueves, 17 de Febrero de 2005 01:46, Joe Marcus Clarke escribió:
> On Mon, 2005-02-14 at 10:09 +0100, Jose M Rodriguez wrote:
> > I'm taking a step ahead in my mozilla/firefox works and I'm
> > thinking about a browser-hier port to cope with things like
> > browser-plugins/
> >
> > Any comments on this will be welcome.
>
> Actually, gnomehier is moving away from its current model to an
> mtree-based model.  I'd like to see browser_plugins (or whatever is
> decided as the common FreeBSD-native plugin directory) be added to
> one of the system mtree files.

I think that the main problem is how this is take now.

- This is done from port Makefile, so you can't tweak this at package 
install time.  I have a patch to solve this (ocming soon), but I don't 
like too much what I must do.

- This is take only from browser package scripts, not from plugins.

I think that a browser-hier package may permit run depends all on it 
(mozilla, firefox, java, flash, kdebase, ...) and work on a more 
reliable set of package scripts from all the components.

>
> > Also, to cope with extensions reinstall with browser reinstall, I'm
> > thinking about source components installed from other ports in
> > browser pkg-install modular scripts, but I can't see any port doing
> > something similar
>
> How would you handle deinstallation with extensions and themes if
> done from ports though?
>
> Joe

Well, this can be large.

I think that I can take this well for mozilla, but I don't think so for 
firefox/thunderbird official builds.

The main question is how to take this: in a parametric form or in a 
functional form.

As a parametric from, I can merge code into main pkg-scripts and read 
parameters from previous installs.

In the mozilla case, my main problem is regenerate installed-chrome.txt 
after reinstall. I may use a chrome.d/ for installed-chrome components 
(dist, lanpacks, extensions ...) and regenerate installed-chrome.txt 
from that in regchrome works (debian do this with success).

The funtional way maybe move this code to MOZLIBDIR/register.sh and 
source/invoke this instead of merge code to all the pkg-scripts

ALso, I'm thinking in have something in the way of RC_SUBR to make very 
common pkg-scripts works as sh funtions (${LOCALBASE}/etc/pkg.subr, 
${X11BASE}/etc/pkg.subr) to be sourced.

But someone may find this open to exploits or break some rules about 
ports. Let me know

The firefox/thunderbird case is another history.  Both the need to make 
official builds and the way the stock extension manager works make this 
a complicated task.

I'll prefer import the debian patches (only to the extension manager) 
and don't rm -rf extensions/.

In any way,  I think that we may declare any extension to 
firefox/thunderbird in the tree broken and work a solution out of 
ports.

We may live with user installed extensions/themes if we add what we 
really need: some solution to extensions that not need only js 
(enigmail).

If we add the ports to make those .xpi and some notes about how to 
import from firefox/thunderbird, people will be happy.

And we gets time to get a real, proven solution for AVIARY_1_5.

Also, this can be another working point: make the extensions/themes for 
seamonkey/firefox/thunderbird a two pass work.

We may use several ports to make/obtain the .xpi and use app-related 
ports (or pkg-scripts components) to merge supported extensions from 
main repository.

This makes posible install an extension from ports (chatzilla) in all 
the installed apps that support it (mozilla, mozilla-devel, firefox).

--
  josemi