From owner-freebsd-ports@FreeBSD.ORG Thu Feb 17 09:21:56 2005 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD89C16A4CF; Thu, 17 Feb 2005 09:21:56 +0000 (GMT) Received: from 212.106.253.169.adsl.jazztel.es (212.106.254.61.adsl.jazztel.es [212.106.254.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D25343D53; Thu, 17 Feb 2005 09:21:54 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) j1H9Lpad005423; Thu, 17 Feb 2005 10:21:51 +0100 (CET) (envelope-from josemi@freebsd.jazztel.es) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.1/8.13.1/Submit) id j1H9MhXE004005; Thu, 17 Feb 2005 10:22:43 +0100 (CET) (envelope-from josemi@freebsd.jazztel.es) X-Authentication-Warning: orion.redesjm.local: freebsd set sender to josemi@freebsd.jazztel.es using -f From: Jose M Rodriguez To: Joe Marcus Clarke Date: Thu, 17 Feb 2005 10:22:42 +0100 User-Agent: KMail/1.7.2 References: <200502141009.30599.freebsd@redesjm.local> <1108601165.48333.1.camel@shumai.marcuscom.com> In-Reply-To: <1108601165.48333.1.camel@shumai.marcuscom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200502171022.42723.josemi@freebsd.jazztel.es> X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.29.0.8; VDF: 6.29.0.100; host: antares.redesjm.local) cc: ports@freebsd.org cc: FreeBSD GNOME Users Subject: Re: About a browser hier-like module X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 09:21:57 -0000 El Jueves, 17 de Febrero de 2005 01:46, Joe Marcus Clarke escribi=F3: > 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. =2D This is done from port Makefile, so you can't tweak this at package=20 install time. I have a patch to solve this (ocming soon), but I don't=20 like too much what I must do. =2D 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=20 (mozilla, firefox, java, flash, kdebase, ...) and work on a more=20 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=20 firefox/thunderbird official builds. The main question is how to take this: in a parametric form or in a=20 functional form. As a parametric from, I can merge code into main pkg-scripts and read=20 parameters from previous installs. In the mozilla case, my main problem is regenerate installed-chrome.txt=20 after reinstall. I may use a chrome.d/ for installed-chrome components=20 (dist, lanpacks, extensions ...) and regenerate installed-chrome.txt=20 from that in regchrome works (debian do this with success). The funtional way maybe move this code to MOZLIBDIR/register.sh and=20 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=20 common pkg-scripts works as sh funtions (${LOCALBASE}/etc/pkg.subr,=20 ${X11BASE}/etc/pkg.subr) to be sourced. But someone may find this open to exploits or break some rules about=20 ports. Let me know The firefox/thunderbird case is another history. Both the need to make=20 official builds and the way the stock extension manager works make this=20 a complicated task. I'll prefer import the debian patches (only to the extension manager)=20 and don't rm -rf extensions/. In any way, I think that we may declare any extension to=20 firefox/thunderbird in the tree broken and work a solution out of=20 ports. We may live with user installed extensions/themes if we add what we=20 really need: some solution to extensions that not need only js=20 (enigmail). If we add the ports to make those .xpi and some notes about how to=20 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=20 seamonkey/firefox/thunderbird a two pass work. We may use several ports to make/obtain the .xpi and use app-related=20 ports (or pkg-scripts components) to merge supported extensions from=20 main repository. This makes posible install an extension from ports (chatzilla) in all=20 the installed apps that support it (mozilla, mozilla-devel, firefox). =2D- josemi =20