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>