On Jul 25, 2008, at 9:44 AM, Michael Alger wrote:
On Thu, Jul 24, 2008 at 12:06:42PM +0200, Andrew Beekhof wrote:
Now that Pacemaker is no longer part of Heartbeat, CRM development
has
been split into two streams (stable and unstable/dev), the packages
at
that location are highly likely to be the best we've produced up to
that point in time. As much as we try to prevent it, occasionally a
regression will slip through, but as a whole they get better and
better (because they're feature frozen).
Fair enough; that's why we have test environments.
When you update is entirely up to you and your organization... I
recommend looking through the changelogs to see if there is anything
relevant to your configuration.
Particularly anything labeled with the "High:" prefix
Sounds like a good plan.
The other thing that I meant to mention, was that the motivation for
releasing so often is essentially to give admins a choice.
By releasing often, chances are that the latest version will already
have a fix for whatever issue you're experiencing.
I much prefer being able to point people to pre-built (and well
tested) packages than
* recommending packages I know to have (many) bugs
* asking people to wait even longer for something that fixes a bug we
knew about long before they found it... or worse,
* requiring people to create custom versions by backporting patches
Also, by reducing the time between releases the code actually becomes
more stable (because less has changed, particularly since no features
are added), regressions are found sooner and it's easier to do a
release.
So by all means, adhere to a if-it-isn't-broken-don't-fix-it policy...
my goal however, is that if your cluster does break, you'll be a
download away from a resolution. Plus the bit about watching the
changelogs of course :-)
On Tue, Jul 22, 2008 at 18:12, Michael Alger <[EMAIL PROTECTED]>
wrote:
Finally, a more specific question: I'm currently using this package
from Debian_Etch/i386 @ the above:
1031100 2008-05-17 02:57 heartbeat_2.1.3-18_i386.deb
Looking at the listing now, the 2.1.3-18 package has a modified date
of 18-Jul-2008. So I downloaded it again, and get this:
1031094 2008-07-18 21:37 heartbeat_2.1.3-18_i386.deb
Clearly the file has been modified (slightly), but the version
number remained the same. Is this a common occurrence? I extracted
the new .deb but the changelog and changelog.Debian haven't changed.
Not sure what the first number is, but the debian packages also get
rebuilt whenever the rpm .spec file is changed.
Perhaps thats what you're seeing.
The first number (1031100, 1031094) was the file size in bytes, as
output by ls. I extracted both packages and did a recursive diff,
and it found differences in all the gzipped documentation (txt and
man pages). I uncompressed them and tried again, and no differences
were found. Presumably the difference was the timestamp within the
gzip header.
So, I think you're right: the .spec was changed for some reason and
so the packages were rebuilt. Was just a bit worried I couldn't go
by the package version numbers to know when it's been updated, but I
guess I still can. Thanks, Andrew.
If the debian version doesn't change, then its highly unlikely* the
source or binaries changed.
* Unless I mess up badly
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
