Re: SeaMonkey 2.35b7

On Sun, 7 Aug 2016 05:03:21 UTC, Steve Wendt <[email protected]> 
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.
> 
> 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.

I think that a) will be an option, in the near future, and that will 
make other methods obsolete. If you haven't looked seriously at 
installing, and using Arca Noae Package Manager (ANPM), I suggest that
you do so. It makes life a whole lot easier. I don't agree with the 
way the RPM/YUM does things, but that is the way that was chosen by 
those who do it, so we are stuck with it, and it will become even more
important to follow that path in the future as more programs are 
packaged that way. The whole thing is a LOT better than it was when 
the ANPM project was started, and ANPM makes it easy to operate 
RPM/YUM.

On the other hand, option b) may become necessary just to overcome the
shared memory problems, but that doesn't mean that it can't be 
distributed by RPM/YUM. After doing some investigation, we need to get
high shared memory working (it does work, as long as you never unload 
the DLLs), or we need a way to keep, at least, XUL.DLL (perhaps 
others) loaded all of the time (preferably high),  so it doesn't run 
into a situation where it can't get enough contiguous memory to load. 
It also needs to be fixed so that it just fails when it can't load the
DLLs. Now, it seems that it just keeps retrying, until the user 
reboots (and a user won't know what is going on, if they don't have 
Process Dumps enabled). I would also suggest that those who use only a
browser, should use FF. Those who use only e-mail, (and news etc.) 
should use TB. Those who need both, should use SM. The idea is to have
only ONE XUL.DLL loaded. Apparently, if you can get the right one, 
they can all share XUL.DLL, but that seems to be hit and miss, at the 
moment. In fact, part of the answer may be to simply drop FF and TB, 
and only update SM, but SM is not an "official" project, so that 
causes other problems.

I will note, that I gave up trying to verify requirements, with 
WarpIn, because Bitwise gave up trying to document that stuff (too 
complicated), and simply said to use RPM/YUM (meaning ANPM to make it 
easy). I did consider looking to see if the user has RPM/YUM 
installed, and simply run the command to do the updates, if it was 
found, but that didn't seem to be a good idea if the user had it 
installed, but wasn't actually using it. As it turned out, those who 
use ANPM spent about 2 minutes (depending on download speed) getting 
the requirements installed, and those who don't use ANPM spent days 
trying to figure it out. Steve made that much easier, but his package 
still doesn't contain all of the parts that ANPM includes, and it will
be the same thing next time. Possibly worse.

One thought (Dave, perhaps you can do something), is to have a program
that will simply load XUL.DLL, and keep it loaded in high shared 
memory space when FF is closed. currently, it seems to take about 90 
meg to load XUL.DLL, and it seems that that must be contiguous memory.
If another program loads something after that, and it stays in memory 
when FF is closed, and something else  uses another chunk of shared 
memory, it can come out of the part that XUL.DLL was using. Now, when 
XUL.DLL tries to load, it can't find enough contiguous shared memory 
space to be able to load XUL.DLL. That just happened to me, and the 
result was repeating Process Dumps, all pointing to Firefox (no *.TRP 
files, or entries in POPUPLOG.OS2). That kept on repeating until I 
rebooted. If XUL.DLL was loaded, and stayed in memory, that problem 
wouldn't happen. Of course, FF should also detect that it couldn't 
load the DLL, and inform the user of the problem.

-- 
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)