Date: Fri, 28 Apr 2006 01:46:36 +0400 From: "Andrew Pantyukhin" <infofarmer@gmail.com> To: "Thierry Thomas" <thierry@freebsd.org> Cc: FreeBSD Ports <ports@freebsd.org> Subject: Re: www/xpi-adblock: patch for Makefile.xpi. Message-ID: <cb5206420604271446h39fe9f05pd857a837753a99c0@mail.gmail.com> In-Reply-To: <20060427203225.GC5792@graf.pompo.net> References: <20060426213510.GF97455@graf.pompo.net> <cb5206420604261603v37b021aep9d1cce8b11998a98@mail.gmail.com> <20060427192103.GB5792@graf.pompo.net> <cb5206420604271256i1ee2e941v6ef25aa0dd69566a@mail.gmail.com> <20060427203225.GC5792@graf.pompo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Me and Thierry Thomas have been working on a new xpi infrastructure. I'm starting to cc our current discussion to ports@ so that other people can catch up and throw in some ideas. See www/xpi-adblock/Makefile.xpi for details. On 4/28/06, Thierry Thomas <thierry@freebsd.org> wrote: > Le Jeu 27 avr 06 =E0 21:56:40 +0200, Andrew Pantyukhin <infofarmer@gmail.= com> > =E9crivait: > > Anyway, we'll need a separate dedicated port, something > > like sysutils/xpi-tools, which will install a shell script for > > dealing with linkfarming. xpi-* will depend on it and the > > script will be called from plists. > > I don't like this idea of a separate port... > > > Then we'll need to add linkfarming/linkcleaning to plists > > of all target apps - to make things shine. > > Maybe we could add these lines in the generated plists from > Makefile.xpi (or define a PKGINSTALL / PKGDEINSTALL). > If we get some .xpi ports, it would be possible to create a bsd.xpi.mk. Okay, I don't like the idea of a separate port myself, but here's how it looks from my point. Packages should support all the functionality of our system. This includes relinking/unlinking after installation. Now user has to "cd /usr/ports/www/xpi-something && make relink". But what if a user doesn't have /usr/ports at all? This implies an executable (or a set thereof) which is common to all xpi- ports. We can employ some hackery to hide the exec inside each package, install/deinstall it in a clever way so that illusion of a common file is created. The downside is replication of the same data between a potentially large number of ports. If we're going to extend the scripts (which I hope we are) this can get annoying. Also, it will be much harder to persuade the maintainers of different apps to include our hacks in their plists/pkg-install/pkg-deinstall, ports like firefox are complicated enough even without our inventions. Come to think of it, a separate port/package is not that bad. It will just install a couple of scripts (probably bin/xpi-{relink, unlink} and some more later). It will help us avoid unnecessary complications. And if a user has 10 xpi-ports installed, will an additional one really matter? > > Then come various design decisions, like how to control > > relinking, where to install xpi (note, BTW that they are now > > installed in LOCALBASE because I didn't want to depend > > on xorg-libs. I think I'll change to X11BASE without toggling > > USE_X_PREFIX later) and so on... > > LOCALBASE is a wiser choice: many people think that X11BASE sould be > kept only for XFree86 / x.org files; it's why KDE installs under > LOCALBASE. I like this approach, too. I guess we'll stick to it. > > Note that this xpi management is one of those things where > > ports system shows its full strength. I'm sure some people > > will find running portupgrade a more comfortable way of > > updating extensions, than using built-in tools. Moreover, > > hopefully we'll provide different interoperability hacks which > > sweeten the deal. > > Yes, especially to install site-based extension without running firefox > as root! Another point is to be referenced within the ports tree, with > search tools like `make search' or freshports.org. Yep, many extensions (like xpi-mldonkey, not committed yet) are very nice but widely unknown just because they are not present at https://addons.mozilla.org/ Thanks!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cb5206420604271446h39fe9f05pd857a837753a99c0>