Re: SeaMonkey 2.35b7

On 08/06/2016 05:13 PM, Peter Brown wrote:

> I did download all necessary packages from Steves Warpzilla site - Thank
> you Steve for figuring out and packaging required files.

I'm glad you found it useful; no one has commented recently, so I wasn't 
sure if anyone else still cared.  :)

> Problem Resolved : Operator Error - Failed to read the mozsupport.txt
> before attempting to run seamonkey.
>
> Having rectified my error I discovered that the files in the nss
> directory in the mozsupport package needed to be on the libpath.

I was conflicted about keeping those in a separate folder, but I figured 
having to RTFM because it didn't work was better than having DLL 
conflicts because of not RTFM.  I could probably be convinced to change 
the packaging structure if there are good arguments.

Personally, I just stuck the nss/nspr files in the SeaMonkey folder, 
since I don't really consider those "shared" at this point.  I may 
change my opinion if I ever care to run something else that depends on 
them (I am unlikely to run VirtualBox).

As an aside, the way they are built right now is in some ways 
unfortunate, as it means there are duplicate libraries linked in now; 
sqlite3 plus mozsqlit3 is one, but there may be others.

Back when IBM was building Mozilla, they took great care to avoid any 
licensing issues and DLL conflicts, statically linking or using DLLRNAME 
to make private versions of DLLs.  Others that followed mostly tried to 
stick to that, but what we have now is quite the opposite.  The "new 
way" has some advantages of its own, but the ability to create a clean 
install package is definitely not one of them.

I've mentioned before that I think there's room for two means of 
packaging and distribution here:

a) yum install seamonkey thunderbird firefox
I believe this is the eventual goal of bitwise, but as everyone knows, 
this simply does not work yet.

b) static build with minimal external dependencies, like Mozilla 
distributes, and we had previously.  Both ZIP and installer package 
(WarpIn or otherwise) are perfectly viable.

Doug has been making WarpIn packages for quite some time, which I 
commend him for, but I feel they are currently pointless, since it 
doesn't do anything about dependencies.  Isn't the point of an 
installation package to set everything up for you?  I'm not faulting 
Doug for that, just pointing out that option b above is what needs to be 
packaged for it to be viable.