The replacement update mechanism will be a script installed on your
system. The advantage of downloading the update mechanism before
running it is that it allows you to upgrade the upgrade mechanism.
Naturally the disadvantage is that you have to download it. Debian
systems have a mechanism for this; we'll use it.
The developer information about how you can specify the source for
scripts and binaries has been having some problems, including for
upgrades. The decision not to support upgrades from wheezy makes it
easy to stop supporting wheezy's upgrade mechanism and begin the
migration toward doing it right. Doing it right places much greater
emphasis on upgrade security and integrity.
The developer side of this was that the scripts ran themselves straight
off a web server. That's just a problem in general, and it too will be
fixed shortly.
The downloading of binary components is the last thing... The right way
to do this is follow the lead of @dschmenk and package this stuff
properly which gains us much of that upgrade integrity/security I spoke
of. That'll be a multi-step migration of its own.
This will be documented as it is implemented, but here's a heads up.
This script well predates wheezy, and we certainly won't support
upgrades from pre-wheezy at this point. Actually, I've made the
decision not even to support upgrades from wheezy in A2SERVER itself,
properly speaking. We'll see if we can write an external upgrade script
(much like this one) to help make transitions a little better, but
that's the best we're going to be able to do here.
It's understandable why you might want to pull this off a server in case
how you have to upgrade things changes for some reason, but we're moving
toward following Debian's lead on these things to the greatest extent
possible.
Okay Ivan, you can "I told you so" now. I didn't see any major gotchas
to changing the version and was SURE there'd be no reason to write the
convoluted comparison function until after everything was nicely redone
and restructured and whatnot. Fortunately I only need it in the main
script for now, and will hopefully very soon be able to just load it
from a common function file and use it where needed.
I still don't regret doing it, but all the work I had to do in order to
make sure I didn't screw it up (or rather that I fixed it after screwing
it up) are totally on me.
What's still missing from this is a version comparison mechanism. The
reason why it is missing is that we only use this in one place at the
moment, and if you have a version string that is not three digits, your
version is recent enough. This means we can save this for when there
are a common functions script to import and make the comparisons for us
without code duplication.
Ivan writes pretty dense scripts in some ways, but not others. Mostly
he likes to collapse statements to a single line and using && and || in
place of if constructs. Reduces file size and theoretically speeds
execution, but it makes community development tougher and the speed
gains are questionable.
I've begun removing multiple successive writes to a single file such as
those using tee as a means to write files as root. Clean up enough of
those and you will have a noticable performance impact, although again
there's no evidence there are enough of them here to see one.
Removed a few dead/commented code blocks and restructured a couple of
conditionals to make the no-action condition the else case.
Finally, bumped the version. This isn't all that'll go into 1.5.1 but
it's a start.
One of the reasons I held off on doing this before is that there are a
lot of complex one-line seds in here that I expect _will_ be broken by
this. More than a few of these will assume, depend on, require, and
break if specific hardcoded whitespace is not found. That's problematic
anyway--when whitespace isn't syntactic, you shouldn't do that. So it's
time to fix these anyway.
Put a couple of filenames in code spans so that _ characters in them
would not turn on unwanted <em> in HTML. This is something GitHub's
Markdown markup doesn't do because it's almost never what you want, but
everything else does because that's what John Gruber designed.
Found some checks that assumed all Debian was wheezy, and also a bunch
of use of cut assuming that there will never be a Debian version higher
than 9.0. Let's just futureproof that code right now. This closes#56
and uses the method described therein anywhere -c 1 is used now. For
the checks against -c 1-2, we still use -d . -f 1 as described in the
issue, but modify the following conditionals to test for just the
numeric, without the decimal.
