PATCH: make contrib/redhat/sshd.init work with older RH releases

[Jim Knoble]

Circa 2001-Feb-17 22:14:37 +0200 dixit Pekka Savola:

: On Sat, 17 Feb 2001, Jim Knoble wrote:
: > Remember also that in RHL-7.0 (and in FHS >= 2.0), the location of
: > 'init.d' changes.  This looks more robust to me:

  [...]

: IMO this is rather unnecessary thing to worry about yet.
: /etc/rc.d/init.d work just great too, because of symlinks.  Those
: aren't going to be removed any time soon I think.  No need to make
: this more complex than we have to.

I disagree.  If you want to fix it properly at this time, this is
exactly the sort of thing to worry about.  Are you certain RH will
leave the compatibility symlink in RHL-7.1?  I'm not.

If you don't want to worry about this sort of thing right now, then i
suggest that we leave well enough alone and fix things properly in the
release after v2.5.0.

: > The problem is with redefining the stock functions is that success()
: > and failure() work slightly differently than the equivalent actions for
: > RHL <= 5.2. [...]
: 
: It'd appear to me that your success()/failure() work differently from my
: proposal only if success/failure haven't been provided by initscripts at
: all.

You are correct in saying that, if success() is defined, the following
are equivalent:

  my_success "Something happened" "Something"
  success "Something happened"

However, in order to do the right thing with your suggested method, we
would have to do:

  success "Something happened" "Something"

which, although equivalent to the two above right now, since RH's
success() ignores $2, may not work in the future.  We have no guarantee
that it will work even for the next release.  my_success(), on the
other hand, is guaranteed to work in that instance.

: My concern is this:  I wouldn't like a huge amount of development work
: going into versions only very few people use.  There should be some sane
: limit of backward compatibility.

There is.  I didn't ask for compatibility with Red Hat Linux 3.0.3 or
2.x.  ;)  And i've already done most of the necessary work; additional
work is cosmetic.

: That is, I'd like to be able to state:
: 
: At the moment, we only support Red Hat Linux 6.x (all errata installed)
: and Red Hat Linux 7.x (all errata installed).

Why abandon folks who have boxes that have been working successfully
for some time and have no pressing need to upgrade (other than the sort
of attitude you appear to be displaying)?  Red Hat Linux 5.2 is no more
obsolete than, say, NeXTstep 3.x or 4.x, HP-UX-10.x, IRIX-5.x,
SunOS-4.x, all of which are listed in configure.in.

The solution i've proposed will work fine on Red Hat Linux 5.2, and
coincidentally on 4.2 as well, without posing any additional troubles
to 6.x, 7.0, or subsequent releases.

: And when a new feature is added, I wouldn't like to have to consider
: what might happen with a 3-year old system, where RPM is ancient,
: initscripts doesn't support anything, etc.

RPM shouldn't be ancient for RHL-5.2; the current recommended level is
3.0.5-9.5x, same as for RHL-6.2.  Same for RHL-4.2.  And regardless,
specfiles are much less important to get backwardly compatible than
initscripts, which (even though in ./contrib/) are much closer to being
part of the software.

: Backward compatibility is OK, but
:  1) it shouldn't affect "currently supported" versions

What i've done doesn't.

:  2) it should be transparent

What i've done is.  my_success() works everywhere.  What's the problem?

And don't forget:

  0) compatibility should be resistant to potential future changes.

and:

  3) it should be obvious what's been done to achieve compatibility.

Calling my_success() makes it obvious to the onlooker that something
besides success() is necessary in certain cases.  Calling success()
doesn't.

: That is why I'd prefer redefinitions of "echo", "success" etc.
: functions rather than new functions;

Redefine echo with a function?  Surely you must be joking.  That's as
bad an idea as C++'s operator overloading: If '+' doesn't add two
numbers, then don't call it '+'; call it something else.

: those that have recent versions shouldn't use these at all (there
: are always issues; what will happen if you want to pass e.g.
: ssh-keygen -N '' to action or the like; you would be amazed at the
: number of \'s required..)

Do we use action()?  Last i checked (SNAP-2001-0216), we didn't.  I
hope we don't; it's not very robust, at least in RHL-6.x.  In
particular, initlog's handling of command arguments is poorly designed.

-- 
jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/