230598 - (solarispatchchecker) RFE: Add Solaris patchchecker to Mozilla

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, enhancement)

Description

[Roland Mainz]

Many many Solaris-specific bugs here in bugzilla are caused simply due the fact
that people do not apply patches to their system BEFORE running Mozilla).
Finally, after some IRC discussion we think it may now a good idea to add a
patch checker script to Mozilla's startup script which is run each time Mozilla
gets updated and checks for patch requirements.

Comment 1

[Roland Mainz]

Some quick notes/commets/etc. from the discussion:
- The patch script has to run BEFORE Mozilla gets executed (to work around
problems like the profile data corruption due missing iconv patches)
- The patch script should be part of the default Mozilla distribution - but only
for Solaris/SPARC + Solaris/x86 (best solution would be a plugin mechanism as
described in bug 230468 ("RFE: mozilla should provide a simple way to run custom
shell scripts at mozilla startup and shutdown")

Comment 2

[Roland Mainz]

Suffering is all mine...

Comment 3

[Roland Mainz]

Attachment: Mozilla patch checker main script ("moz_patch_checker.sh"), version 0.01

ToDo:
- Better message texts (suggestions welcome :)
- The patch needs to locale the mozilla binary, check the date stamp and only
starts checking for patches when the date stamp or file size has changed
(otherwise we check the patches every time... adding ~~5-15secs to the startup
time).

Comment 4

[Roland Mainz]

Attachment: Screenshot, the script complaining about missing patches

Comment 5

[Jo Hermans]

- license issues : new files are supposed to use MPL/GPL/LGPL triple-license
- does every system have dtksh installed ?
- eh, you should better remove those references to Satan ... Nice test, but I
can imagine the bug-reports ;-)

Comment 6

[Roland Mainz]

Jo Hermans wrote:
> - license issues : new files are supposed to use MPL/GPL/LGPL triple-license

I can make it even quad-license on demand MPL/GPL/LGPL/MIT ... :) Maybe the
legal stuff then becomes larger than the script itself.

> - does every system have dtksh installed ?

Yep. Trying to remove it will render CDE unuseable (dtksh is part of CDE).

> - eh, you should better remove those references to Satan ... Nice test, but I
> can imagine the bug-reports ;-)

I know... I'll remove them for the final version... :)

More ToDo:
- Fix the typo in the intro message
- Need to fix bug 230468 first to get the pluggable scripting framework

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

What's the difference between the dismiss and exit buttons? Just the returncode?
If so, why do we need two buttons there?

Comment 8

[Roland Mainz]

Christian Biesinger wrote:
> What's the difference between the dismiss and exit buttons? Just the 
> returncode?

Yes... the glue for that will be a small plugin script (based on the framework
created with bug 230468) which calls the patch checker on demand (e.g. mozilla
binary changed) and checks for the return code of the patch checker script (I am
using two sepeate scripts (one "script plugin" and the patch checker script
itself (this is mandatory anyway since the "mozilla" script uses /bin/sh (bourne
shell) and the patch checker dtksh (Korn Shell 93 with X11/Motif/CDE support)))
here to allow that the patch checker can be used from both "mozilla" and the XPI
installer).

> If so, why do we need two buttons there?

The user should have two choices:
a) "Continue" ("Dismiss" may be misleading... another ToDo item), ignoring the
risk of damaging his profile data
b) "Exit" - then the script exists WITHOUT starting Mozilla (for the case that
the user wants to install the patches (or hunts the admin down and force him/her
to install the patches).

One open question is whether [a] ("Continue") should disable the patch checker
([b] just exists and the patch checker runs again the next time) or whether
there should be seperate a "Continue - and don't show this dialog again"-button.

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

>a) "Continue" ("Dismiss" may be misleading... another ToDo item), ignoring the
>risk of damaging his profile data

hm, I'm not sure there's value in providing users with a "destroy profile" button...

Comment 10

[Roland Mainz]

Christian Biesinger wrote:
> >a) "Continue" ("Dismiss" may be misleading... another ToDo item), ignoring 
> the
> >risk of damaging his profile data
>
> hm, I'm not sure there's value in providing users with a "destroy profile" 
> button...

The patch checker dialog is thought as a _reminder_ mechanism ("pester
mode"-style :).
If people really want to continue than the patch checker should not prevent
people from doing so (otherwise the people will rant a lot and start looking for
ways to bypass the patch checker somehow, maybe causing more problems than the
missing patches... ;-/). They have been warned... if they continue - ignoring
the warning - then that's their fault. We did everything we could do in that
case.

Comment 11

[Mick Kelleher]

I think the patch check is a really good addition but i think there should be 
an flag to disable the check when mozilla is starting (something like... 
mozilla -nopatchcheck) or a preference setting somewhere in 
$MOZILLA_DIR/defaults/pref. I have all our machine's patch level's up to date, 
and you'd be surprised how many users will judge a browser by how fast it 
start's up.

I do like the idea that the patch check is turned on by default as it's a good 
reminder to me when i'm testing Mozilla before deployement.

Comment 12

[Roland Mainz]

Mick Kelleher wrote:
> I think the patch check is a really good addition but i think there should be 
> an flag to disable the check when mozilla is starting (something like... 
> mozilla -nopatchcheck)

This is planned anyway since Mozilla.org's tinderbox machines are usually NOT
up-to-date with OS patches (I'll file a bug for that in a few mins). I still
have to think about an anyoing solution which gurantees that people will beg for
the OS patches instead of ignoring the patch checker... =:-)

> or a preference setting somewhere in 
> $MOZILLA_DIR/defaults/pref.

Erm, no. The idea of the patch checker is to run BEFORE mozilla is being
started. The patch checker MUST be independent from the Mozilla binary code to
avoid the problem that even the initial startup phase of mozilla can hit bugs in
the OS.
A good example for the problems we try to avoid is bug 231936 ("creates both
.mozill and .mozilla directories when first launched, then cannot find profile
in subsequent launches", and all the DUPlicates of it) which is a user profile
corruption due a bug in the iconv code (it causes various malfunctions within
mozilla). This bug is very anyoing for Mozilla users and there is no proper
workaround except applying the OS patch (OKOK, in theory we could work around
this specific issue with ugly hacks in mozilla's intl code but that would not be
really fair for those people at Sun who work very hard to get the issues fixed
and patches shipped - and then noone uses their work :) - and that still does
not solve the other problems (XIM, Xsun, libCstd etc.) solved by OS patches.
Replicating half the functionality in Solaris just to avoid some bugs isn't
really the job of mozilla folks - that's the reason why there are OS patches :)

Comment 13

[Mick Kelleher]

Hi Roland,

I gave your code a once over and i must admit it's a nice piece of work.
It's a shame we're stuck using 'showrev -p' as it can run really slowly if you 
regularly patch your machine and there is many previous revisions of the same 
patch numbers.
I've just finished a nightmare deployement of Mozilla 1.6 in our department, 
and the problem might not be picked up with the patch check script. I basically 
had a fully patched Solaris 2.8 machine which i compiled Mozilla 1.6 on and 
deployed it across the network to all my Sun's. The following day i had a huge 
amount of complaints from users that Mozilla was crashing continously. All the 
machines both Solaris 8 and 9 have the recommended Mozilla patches we'll above 
the ones on the web site, but Mozilla was still crashing. I ended up having to 
upgrade all my machines C++, and linker patches to the latest from Sunsolve and 
that fixed the problem (not a pleasent job on over 300+ Sun's).
I've noticed the bug when Mozilla 1.6 is compiled with 108435-13+, 108436-13+, 
and 109147-26+ on Solaris 8. I'm not sure whether a warning should be put on 
the recommended solaris patches for Mozilla web page and/or having a warning on 
the patch check script saying that under rare circumstances you might require 
later revisions of the patches then are currently recommended.
I'll probably have to log a new Mozilla bug for this new problem anyway, but it 
does seem to be relevent to the patch checker script aswell.

Comment 14

[Roland Mainz]

(In reply to comment #13)
> Hi Roland,
> 
> I gave your code a once over and i must admit it's a nice piece of work.
> It's a shame we're stuck using 'showrev -p' as it can run really slowly if you 
> regularly patch your machine and there is many previous revisions of the same 
> patch numbers.

I knpw that problem and I am going to add a "cache" for that to avoid such
problems. The patch checker should only be started if mozilla was updated.

> I've just finished a nightmare deployement of Mozilla 1.6 in our department, 
> and the problem might not be picked up with the patch check script. I basically 
> had a fully patched Solaris 2.8 machine which i compiled Mozilla 1.6 on and 
> deployed it across the network to all my Sun's. The following day i had a huge 
> amount of complaints from users that Mozilla was crashing continously. All the 
> machines both Solaris 8 and 9 have the recommended Mozilla patches

Really ? Where did you get the patch list from ?

> we'll above 
> the ones on the web site, but Mozilla was still crashing. I ended up having to 
> upgrade all my machines C++, and linker patches to the latest from Sunsolve and 
> that fixed the problem (not a pleasent job on over 300+ Sun's).
> I've noticed the bug when Mozilla 1.6 is compiled with 108435-13+, 108436-13+, 
> and 109147-26+ on Solaris 8. I'm not sure whether a warning should be put on 
> the recommended solaris patches for Mozilla web page and/or having a warning on 
> the patch check script saying that under rare circumstances you might require 
> later revisions of the patches then are currently recommended.

I guess I have to update the patch list. Since the last time I composed the list
on mozilla.org www pages was when I was using Sun Workshop 7... >mozilla1.5 was
compiled with Sun Workshop 8 which may have introduced the requirement for newer
libCstd versions (which means (for me): AHHHHGGRRLLL... another four hours of
patchadd/patchrm+smoketesting to figure the minimum requirements... ;-( ) ...

> I'll probably have to log a new Mozilla bug for this new problem anyway, but it 
> does seem to be relevent to the patch checker script aswell.

Please file one and assign it to me that I can update the mozilla.org www pages.

Comment 15

[Roland Mainz]

BTW: So many people say they like the idea... where are your votes ? Where ? :))

Comment 16

[Roland Mainz]

Attachment: S02solaris_patchchecker.sh V0.1

S02solaris_patchchecker.sh
Steps for installation:
1. Copy it to dist/bin/init.d/S02solaris_patchchecker.sh
2. Copy the patch checker main script to dist/bin/moz_patch_checker.sh

That's all... :)

Comment 17

[Roland Mainz]

bsmedberg:
Where should I store the files in CVS - is mozilla/xpfe/bootstrap/init.d/ (a
seperate dir since a lot of scripts may be added here in the future) a good
place assuming that those scripts should be used for
Firebird/Thunderbird/Sunbird later, too ?

Comment 18

[Roland Mainz]

Attachment: Mozilla patch checker main script ("moz_patch_checker.sh"), version 0.02

Updated version of the patch checker, typos fixed, lines which summon Satan
removed etc. etc.

Comment 19

[Roland Mainz]

Attachment: Patch for 2004-02-06-trunk

Comment 20

[Roland Mainz]

Attachment: Patch for 2004-ß2-06-trunk (now sets +x flags for scripts)

Comment 21

[Roland Mainz]

Comment on attachment 140717 [details] [diff] [review]
Patch for 2004-ß2-06-trunk (now sets +x flags for scripts)

Requesting r= ...

Comment 22

[Benjamin Smedberg]

Comment on attachment 140717 [details] [diff] [review]
Patch for 2004-ß2-06-trunk (now sets +x flags for scripts)

I am utterly incompetent to review this code. I have a few nits here, but this
should be carefully reviewed by someone who knows solaris. I am not a
super-reviewer, but blizzard normally gives a blanket sr for platform-specific
code like this. With a careful review + blizzard's OK, MOA=me

>Index: xpfe/bootstrap/init.d/Makefile.in

When you add makefiles, you also need to add them to allmakefiles.sh.  Whenever
this actually lands, ADD THE NEW FILES FIRST, wait an hour, then commit
xpfe/bootstrap/Makefile.in to prevent really bad tinderbox badness.

>+# The contents of this file are subject to the Netscape Public
>+# License Version 1.1 (the "License"); you may not use this file

You copied this without looking. Please use MPL tri-license for all new files
(see http://www.mozilla.org/MPL for boilerplate texts).

>+# The Initial Developer of the Original Code is Netscape
>+# Communications Corporation.  Portions created by Netscape are

Nope ;) give yourself credit.

>+PACKAGE_FILE = xpfe.pkg
>+PACKAGE_VARS = USE_SHORT_LIBNAME

these lines should be removed

Comment 23

[Roland Mainz]

Attachment: New patch per bsmedberg's comments

Comment 24

[Roland Mainz]

(In reply to comment #22)
> (From update of attachment 140717 [details] [diff] [review])
> I am utterly incompetent to review this code. I have a few nits here, but this
> should be carefully reviewed by someone who knows solaris. I am not a
> super-reviewer, but blizzard normally gives a blanket sr for platform-specific
> code like this. With a careful review + blizzard's OK, MOA=me
> 
> >Index: xpfe/bootstrap/init.d/Makefile.in
> 
> When you add makefiles, you also need to add them to allmakefiles.sh.  Whenever
> this actually lands, ADD THE NEW FILES FIRST, wait an hour, then commit
> xpfe/bootstrap/Makefile.in to prevent really bad tinderbox badness.

I wish all tinderbox machines would pull by date... but do not worry... I can't
blow-up anything... I have no commit permissions... ;-(
Fixed.

> >+# The contents of this file are subject to the Netscape Public
> >+# License Version 1.1 (the "License"); you may not use this file
> 
> You copied this without looking. Please use MPL tri-license for all new files
> (see http://www.mozilla.org/MPL for boilerplate texts).

I wish we could use quad-liceses which include MIT/X.org's stuff, too... =:-)
Fixed.

> >+# The Initial Developer of the Original Code is Netscape
> >+# Communications Corporation.  Portions created by Netscape are
> 
> Nope ;) give yourself credit.

Fixed.

> >+PACKAGE_FILE = xpfe.pkg
> >+PACKAGE_VARS = USE_SHORT_LIBNAME
> 
> these lines should be removed

Fixed.

Comment 25

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 140723 [details] [diff] [review]
New patch per bsmedberg's comments

>Index: xpfe/bootstrap/init.d/README
> Mozilla/FireBird/ThunderiBird/SunBird.

"FireFox" and "ThunderBird" (spelling).

sr=bzbarsky with that.

Comment 26

[Benjamin Smedberg]

checked in

Comment 27

[Andreas Lange]

(In reply to comment #14)

> I guess I have to update the patch list. Since the last time I composed the list
> on mozilla.org www pages was when I was using Sun Workshop 7... >mozilla1.5 was
> compiled with Sun Workshop 8 which may have introduced the requirement for newer
> libCstd versions (which means (for me): AHHHHGGRRLLL... another four hours of
> patchadd/patchrm+smoketesting to figure the minimum requirements... ;-( ) ...

We had a problem the other day partly related to this. We compiled a 1.6 and
tested for a few days before upgrading our department from 1.5. The test went
surprisingly smooth this time, not a single problem. But after the official
switch, some people had nearly instant crashes. 

It turned out that the machine we had compiled on and our workstations were
upgraded. Other machines were getting the latest reinstallation, 30-40 machines
each night. Machines with the older patchset had the crashes. We traced this to
'__fabsf' beeing linked to libm on our machines and that the older ones didn't
have that symbol. The code using this symbol got called when drawing a <hr> or a
gui button... The relevant patch for this is 111721-04, "4820770 ANSI C++
<cmath> support lacks float and long double signatures".

Comment 28

[Roland Mainz]

Attachment: Fix solve the permission problem

The original patch has a minor flaw, the "executable" bit is missing when doing
a "gmake" xpinstall/packager/, causing Mozilla startup failure. The patch fixes
that.

Comment 29

[Roland Mainz]

Comment on attachment 141162 [details] [diff] [review]
Fix solve the permission problem

Requesting r= and a= for 1.7a

Comment 30

[Benjamin Smedberg]

Reopening for permissions issue.

Comment 31

[Roland Mainz]

Requesting "blocking 1.7a" status, mozilla can't start due lack of permission
problems (ignore the tinderboxen, the patch checker is turned-off for them).

Comment 32

[Mike Kaply [:mkaply]]

Comment on attachment 141162 [details] [diff] [review]
Fix solve the permission problem

a=mkaply for 1.7a

Comment 33

[chris hofmann]

need to get this in soon if its going to make 1.7a

Comment 34

[Roland Mainz]

darin checked-in the patch
(http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?module=MozillaTinderboxAll&branch=HEAD&cvsroot=/cvsroot&date=explicit&mindate=1076532360&maxdate=1076532660&who=darin%25meer.net),
marking bug as FIXED.

Follow-up is bug 233863 ("Recommended patches for Mozilla on Solaris need
updating") to update the release notes and to teach the patch checker about
Solaris/x86 patches.

Comment 35

[Roland Mainz]

The permission problem is still there:
-- snip --
gisburn@north/shared/bigtmp/mozilla/nightlybuilds/north/objdir_gtk1/xpfe/bootstrap/init.d%
gmake libs
../../../config/nsinstall -R -m 755
../../../../mozilla/xpfe/bootstrap/init.d/moz_patch_checker.dtksh
../../../dist/bin
../../../config/nsinstall -R -m 755
../../../../mozilla/xpfe/bootstrap/init.d/S02solaris_patchchecker.sh
../../../dist/bin/init.d
../../../config/nsinstall -R ../../../../mozilla/xpfe/bootstrap/init.d/README
../../../dist/bin/init.d
gisburn@north/shared/bigtmp/mozilla/nightlybuilds/north/objdir_gtk1/xpfe/bootstrap/init.d%
ls -l ../../../../mozilla/xpfe/bootstrap/init.d/moz_patch_checker.dtksh
-rw-r--r--   1 gisburn  gisburn     7121 Feb 10 17:50
../../../../mozilla/xpfe/bootstrap/init.d/moz_patch_checker.dtksh
-- snip --

Can anyone explain this ? nsinstall installs the file with "nsinstall -R -m 755"
but the permission of the "moz_patch_checker.dtksh" remains -rw-r--r-- (should
be: -rwxr-xr-x).

Reopening bug... ;-(

Comment 36

[Roland Mainz]

Attachment: 2nd try to get the permission problem fixed, patch for 2004-02-14-trunk

Comment 37

[Roland Mainz]

Comment on attachment 141431 [details] [diff] [review]
2nd try to get the permission problem fixed, patch for 2004-02-14-trunk

Requesting r= and a{1.7a}= ...

Comment 38

[chris hofmann]

Comment on attachment 141431 [details] [diff] [review]
2nd try to get the permission problem fixed, patch for 2004-02-14-trunk

a=chofmann

Comment 39

[Benjamin Smedberg]

Comment on attachment 141431 [details] [diff] [review]
2nd try to get the permission problem fixed, patch for 2004-02-14-trunk

Hrm, these should have the executable bit set in the CVS repo. But I can't
figure out how to do that now that they are already checked in. Is there a "cvs
admin" command for that?

Comment 40

[Benjamin Smedberg]

justdave, myk, please help with the CVS executable permissions on these files.

Comment 41

[Roland Mainz]

Benjamin Smedberg wrote:
> (From update of attachment 141431 [details] [diff] [review])
> Hrm, these should have the executable bit set in the CVS repo

No, you're wrong here. Other parts of Mozilla use "chmod a+x" for that purpose,
too.
It is NOT guranteed that the packager used to distribute the source tarball
perserves the "exec" bit so the build system should not assume that this
happens.

Comment 42

[Dave Miller [:justdave]]

I was about to say that...  CVS has no concept of file permissions (which is one
of the reasons a lot of people hate it).  The build system needs to deal with
that if you need to assure specific permissions on a file.

Comment 43

[Roland Mainz]

Dave Miller wrote:
> I was about to say that...  CVS has no concept of file permissions (which is 
> one of the reasons a lot of people hate it)

I am wondering why people always scream for such features which are not
"portable" (which means in this case: Portable across both platforms and archive
programs (such as ZIP, plain tar, "plain" cpio)) ... ;-(

Comment 44

[Paul Boven]

The output of showrev -p isn't always in ascending order of patch-revisions. In
those cases, the script will report that the system needs patching even though
it is up-to-date.

$ showrev -p |grep '^Patch: 112785'
Patch: 112785-09 (etc ...)
Patch: 112785-12
Patch: 112785-26
Patch: 112785-30
Patch: 112785-05

This will cause the checker to throw up the dialog claiming that 112785-05 needs
to be updated even though the system is up to date.

Solution: run the output of showrev trough a 'sort -n' first, see attached patch.

Comment 45

[Paul Boven]

Attachment: Patch to sort the patchlist in numerical order

This patch makes sure that we use the highest revision of a patch because the
output of showrev -p is not always ordered.

Comment 46

[Roland Mainz]

Comment on attachment 141522 [details] [diff] [review]
Patch to sort the patchlist in numerical order

Paul Boven wrote:
> The output of showrev -p isn't always in ascending order of patch-revisions. 
> In those cases, the script will report that the system needs patching even 
> though it is up-to-date.

Ahhhhhhggllll...
... if I remember correctly there was a bugid at SunSolve about this and I
thought this was fixed long ago... seems I was wrong... xx@@@! (actually we
have to deal with unpatched machines, too so we need this fix anyway) ...

... can you please attach the same patch but with "gdiff -u" (unified diff),
please (I'll test and r= it then ASAP and ask for a=, too) ?

Comment 47

[Roland Mainz]

Comment on attachment 141431 [details] [diff] [review]
2nd try to get the permission problem fixed, patch for 2004-02-14-trunk

bz checked in attachment 141431 [details] [diff] [review]
(http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?module=MozillaTinderboxAll&br
anch=HEAD&cvsroot=/cvsroot&date=explicit&mindate=1076910660&maxdate=1076911260&
who=bzbarsky%25mit.edu) ...
... lets hope the "sort" patch is the last one... :)

Comment 48

[Paul Boven]

Comment on attachment 141522 [details] [diff] [review]
Patch to sort the patchlist in numerical order

Patch resubmitted as a unified diff

Comment 49

[Paul Boven]

Attachment: Patch to sort the output of showrev -p in ascending order, so the script shows the latest patch number

Patch again, this time in unified diff format.

Comment 50

[Roland Mainz]

Comment on attachment 141530 [details] [diff] [review]
Patch to sort the output of showrev -p in ascending order, so the script shows the latest patch number

r=[e-mail]

Requesting sr= and a{1.7a}= (one-line LOW risk patch, we're just sorting the
list of patches passed to the patch checker).

Comment 51

[Christian :Biesinger (don't email me, ping me on IRC)]

um, wouldn't it be better to sort after the grep, because then fewer lines must
be sorted and that will be faster?

Comment 52

[Paul Boven]

Theoretically, yes.
But I've never seen a working showrev -p output any lines that don't start with
'Patch:' so I don't think there will be any performance gain. Just in case
though, it is prudent to keep the grep in there (a broken showrev can output
other text).

Regards, Paul Boven.

Comment 53

[Roland Mainz]

Christian Biesinger wrote:
> um, wouldn't it be better to sort after the grep, because then fewer lines 
> must be sorted and that will be faster?

The "grep" statement is only there as safeguard in the case that any future
version of "showrev -p" may produce different output (so far this is a NOP from
Solaris 2.7 up to Solaris 2.10, but I cannot gurantee what may happen... say...
in Solaris 2.11 :) ...

Comment 54

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 141530 [details] [diff] [review]
Patch to sort the output of showrev -p in ascending order, so the script shows the latest patch number

sr=bzbarsky

Comment 55

[chris hofmann]

Comment on attachment 141530 [details] [diff] [review]
Patch to sort the output of showrev -p in ascending order, so the script shows the latest patch number

a=chofmann for 1.7a but need to get this in quick

Comment 56

[Christian :Biesinger (don't email me, ping me on IRC)]

Checking in moz_patch_checker.dtksh;
/cvsroot/mozilla/xpfe/bootstrap/init.d/moz_patch_checker.dtksh,v  <-- 
moz_patch_checker.dtksh
new revision: 1.2; previous revision: 1.1
done

Comment 57

[chris hofmann]

thanks. marking fixed

Comment 58

[Roland Mainz]

Followup is bug 233863 ("Recommended patches for Mozilla on Solaris need
updating") to update the patch ids, add the missing patch ids for Solaris/x86
and address Greg Onufers comments he send me via PM...

Comment 59

[Jens Hatlak (:InvisibleSmiley)]

Just wanted to inform you that NOT every system has a dtksh. Our university's
for example doesn't. Thus, the moz_patch_checker.dtksh script and due to that
./mozilla can't be executed. We do not use CDE (at least not where I'm involved)
but let the users choose custom window managers.

Anyway, we have a custom script that executes ./mozilla-bin directly and does
some other things which could be realized using the new init.d mechanism now,
though.

Comment 60

[Roland Mainz]

Jens Hatlak wrote:
> Just wanted to inform you that NOT every system has a dtksh. Our university's
> for example doesn't. Thus, the moz_patch_checker.dtksh script and due to that 
> ./mozilla can't be executed. We do not use CDE (at least not where I'm 
> involved) but let the users choose custom window managers.

1. You can always remove the "init.d/S02solaris_patchchecker.sh" file to get rid
of the patch checker. Or set the "secret" environment variable (read
"S02solaris_patchchecker.sh") to disable it :)
2. You are surprising me... someone really tries to remove /usr/dt/bin/dtksh.
During my admin cert it was always said that removing dtksh will cause
devastating havoc... you're the first one who claims that it isn't that
dramatic... on the other side you said "We do not use CDE" ... which I interpret
that you omitted _ALL_ CDE-related packages (not a good idea either since some
Sun products depend on them and I doubt this is the default setup) ... but that
may work. For that case [1] describes the workarounds...

> Anyway, we have a custom script that executes ./mozilla-bin directly and does
> some other things which could be realized using the new init.d mechanism now,
> though.

That was one if the main ideas behind the new init.d/ mechanism. Nearly every
site I am aware of has modified the ./mozilla shell script to match their needs
which is IMHO unneccesary hackery. The new init.d/ stuff now allows to plug-in
additional scripts used by admins for site management (for example to get rid of
the XUL cache files or fix the permission of the calendar dir in the user's
profile dir) instead of hacking the script directly for each mozilla release
(and users are able to do the same with ~/.mozilla/init.d/ :)

Comment 61

[Roland Mainz]

Attachment: New screenshot, 20040326trunk patch checker in action on Solaris2.8

New screenshot for demonstration.