384714 - Purge moz_pis_startstop_scripts from the tree

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Andrew Schultz]

Attachment: Purge moz_pis_startstop_scripts

bug 230468 added a way to run start/stop scripts at startup and shutdown.  These have only ever been used to check for Sun patches (and Xprint, I think).  The init.d directory that it looks for things in is gone.  So the bits from the scripts that try to exercise this functionality should go to.  If Sun packages still use this, the packager should patch the script to do so.

I don't know who feels responsible for the Sunbird startup script, so cc'ing a couple semi-random devs.

Comment 1

[Robert Kaiser]

Your should probably clean out the Makefile sed rules for MOZ_USER_DIR as well, as those are only used by this section of the script, see http://mxr.mozilla.org/seamonkey/source/suite/app/Makefile.in#211 and http://mxr.mozilla.org/seamonkey/source/browser/app/Makefile.in#279 (probably the ame for other apps).

Maybe it would it be good to remove %MREDIR% (MRE_HOME) in the same step?

Comment 2

[timeless]

i always thought this was a good way of dealing with all the stupid sound driver incompatibilities, but oh well.

Comment 3

[Andrew Schultz]

Attachment: don't fix up MOZ_USER_DIR

As KaiRo mentioned, MOZ_USER_DIR was used for only for the moz_pis*

MRE_HOME has hooks in various other parts of the build system (autoconf.mk.in and rules.mk) and probably deserves its own bug.

Comment 4

[Andrew Schultz]

FIXED

Comment 5

[Robert Kaiser]

(In reply to comment #3)
> MRE_HOME has hooks in various other parts of the build system (autoconf.mk.in
> and rules.mk) and probably deserves its own bug.

Filed bug 386582 for that.

Comment 6

[Noah Friedman]

Sigh.  I am really frustrated that this got removed.  I was using it for personal customizations, since it was documented, in order to annotate MOZ_PLUGIN_PATH and the like.

I see that this bug described the action to be performed, but not the rationale, for stripping away documented functionality.

In the future, if you are going to generalize a kludge beyond the original problem it was meant to solve, you should be very careful removing it since you no longer know the full scope of its usefulness.

Comment 7

[Benjamin Smedberg]

documentation is no guarantee that a feature is worth keeping. And just because something may be useful to someone doesn't mean it's worth the significant maintenance burden.