Re: GNU IceCat?

[Chris Knadle <Chris.Knadle@coredump.us>]

Simon Josefsson:
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> 
>> Simon Josefsson writes ("Re: GNU IceCat?"):
>>> What's a good way to do that efficiently?   People have submitted bugs
>>> against Iceweasel to do some of the things that IceCat does by default,
>>> for example https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654336
>>
>> Well, a good start would be to turn bugs
>>   Severity: wishlist
>> into bugs
>>   Severity: wishlist
>>   Tags: patch
>> ?
>>
>> I'm not surprised that the Iceweasel team don't have much time for
>> anything which isn't strictly essential.  A well-tested and maintained
>> and maintainable patch would make it more feasible.
> 
> Agreed -- part of what I'm trying to understand, though, is whether the
> Iceweasel team considers this a relevant direction to go into?  The
> https://wiki.debian.org/Iceweasel suggests it strives to be close to
> what Firefox is, however that was written almost 10 years ago I'm not
> sure whether it is still true.

It's likely still true, mainly because it's most often true for most Debian
packages in general.  Patching the upstream source can be problematic
because often the patches need re-modification for new upstream versions, so
carrying a lot of patches is usually a maintenance headache.

>>> The normal approach in that situation is to also package the fork of
>>> the projects to give users a choice, similar to what's done with
>>> MariaDB/MySQL.
>>
>> I don't think this is a good engineering solution for a situation
>> where what we're talking about is essentially different configuration,
>> rather than a different codebase.
> 
> I don't think that is what we are talking about -- there appears to be
> more to IceCat than configuration.
> 
> I agree that the differences between IceCat and Iceweasel are small, and
> it is quite far away of resembling the MariaDB/MySQL situation, however,
> at some point separate packaging will become relevant.  We are obviously
> not there yet.

I don't think it's clear.

One option which might help is to package it (in one form or another), put
it in an external repository, and see how well you like the results.
[I'm willing to help you either set up your own external repo, or put the
package in my external repo for you to use.]

>> If you do find that the Iceweasel maintainers are not interested
>> enough in your goals, then a better engineering solution might be an
>> overlay package which overrides some of the configuration defaults.
>>
>> (If there is currently no good mechanism for such an overlay package,
>> that is a generically useful thing which I would expect both Debian's
>> Iceweasel people and indeed upstream Mozilla to welcome.)
> 
> I don't see how such a mechanism would work, but if it was possible that
> would be nice.

I can imagine how it would work, but it's ugly.  It might be best to build a
"dpkg-overlay" tool for the job.  The basic idea would be that dpkg-overlay
would be willing to replace package files and their .md5sum after checking a
replacement .md5sum file that comes with the overlay package.  [This idea
comes from exploits on local Debian packages that I've heard about, BTW.]
The catch is that there'd need to be some way of triggering a
re-installation of the overlay if the package that the overlay is for is
reinstalled.

   -- Chris

-- 
Chris Knadle
Chris.Knadle@coredump.us