Re: SeaMonkey 2.35b7

Steve Wendt wrote:
> 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.

It may have been better to just package up the missing dependencies from 
the last release of SM. They seem to work and don't have extra dependencies.
Of course the new problem is that any work done to NSPR or NSS etc is 
going to happen to the Netlabs versions, so eventually we'll have to use 
them.

>
> 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.

It helped that OS/2 was tier 1 back then, so that when Mozilla added 
libz and the sys2070's started happening on OS/2, the obvious solution, 
prefixing DLLs with moz, was easy to push.
Things like mzfntcfgft were written as much to reduce external 
dependencies as to make it OS/2 specific. There was a time when we 
depended on the real fontconfig.
One thing was that with regular releases, it was easy to update the 
static libraries. Now it's hard to say how  many more releases we'll 
have. After 45ESR it is going to be very hard to update, just due to the 
rust dependency, little well all the build system changes etc.

>
> 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.

It still needs to be decided how. Most Linux dists put the binaries 
somewhere such as under /usr/lib or /usr/share and just have a script in 
/usr/bin to launch. It'd be nice to be able to share all DLLs but not 
sure if it is possible.

>
> 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.

Some of the dependencies seem to not work as static libraries, at least 
Fontconfig and Pango. I tried a static build and managed to get a 
browser that didn't display any text, not even miss-glyph symbols.

>
> 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.
>

Dave