[26324] in Source-Commits

home help back first fref pref prev next nref lref last post

Re: /svn/athena r25514 - trunk/athena/lib/firefox-extension/debian

daemon@ATHENA.MIT.EDU (Jonathan Reed)
Mon May 21 22:49:19 2012

Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Jonathan Reed <jdreed@MIT.EDU>
In-Reply-To: <87k406l8lz.fsf@ratapult.mit.edu>
Date: Mon, 21 May 2012 22:49:16 -0400
Cc: source-commits@MIT.EDU
Message-Id: <93C222F0-F7B4-4F7A-BBBF-E44063BC588F@mit.edu>
To: Benjamin Barenblat <bbaren@MIT.EDU>
Content-Transfer-Encoding: 8bit


On May 20, 2012, at 7:45 PM, Benjamin Barenblat wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On Thursday, May 17, 2012, at 11:41 am EDT, Jonathan Reed wrote:
>> In firefox-extension:
>>  * Instead, figure out whether to add that additional symlink in the
>>    postinst and clean it up in the postrm.  Firefox is moving fast enough
>>    that doing it at build time is wrong, since we don't rebuild the
>>    package every time there's a FF bump
>> 
>> [patch]
> 
> I'm not convinced that doing it at build time is wrong, and we probably
> should be doing builds more often.  Given the existing pattern of
> Debathena builds, however, this seems quite reasonable.  ACK.

Fair enough -- build time is not inherently Wrong(tm).  However, ultimately, it's the state of the machine at install time that we care about (which is why the /usr/lib/firefox/extensions symlink code is in Firefox's postinst).   This is going to to turn out to be moot, however, since the extension has to be re-architected anyway, and that will make it a Gecko 2.0-only extension, which only goes in /usr/lib/firefox-addons/extensions.

-Jon

home help back first fref pref prev next nref lref last post