"Neal Kreitzinger" [off-list ref] writes:
If I only test a new git version (compiled from git.git source) on RHEL6
before I put it on the RHEL5 box is that sufficient for validation? Should
git behave the same on both? If not, why?
I somehow find this a strange question to ask to Git people; you may have
better luck asking the question to RHEL folks.
Having said that, one of the reasons the result may not work, off the top
of my head, is that the binary you compiled would expect to link with the
system libraries that are available on your RHEL6 installation. If your
RHEL5 installation does not have a matching and ABI compatible library to
any of them, the resulting binary would obviously not work there.
On 2/24/2012 4:08 PM, Junio C Hamano wrote:
"Neal Kreitzinger"[off-list ref] writes:
quoted
If I only test a new git version (compiled from git.git source) on RHEL6
before I put it on the RHEL5 box is that sufficient for validation? Should
git behave the same on both? If not, why?
I somehow find this a strange question to ask to Git people; you may have
better luck asking the question to RHEL folks.
Having said that, one of the reasons the result may not work, off the top
of my head, is that the binary you compiled would expect to link with the
system libraries that are available on your RHEL6 installation. If your
RHEL5 installation does not have a matching and ABI compatible library to
any of them, the resulting binary would obviously not work there.
"high-level" question:
If I compile git 1.7.9.2 (from git.git source) on RHEL6 test-box and
test it and conclude that it "works right" is that sufficient for me to
then go ahead and compile git 1.7.9.2 on RHEL5 real-box and
expect/assume that it will also "work right"? IOW, will they produce
the same results? Because if not then I have just potentially broken
the real-box.
"low-level" question:
I suspect git calls linux commands alot. Git has "plumbing" commands
that are not supposed to "break" scripts. Does linux also have
"plumbing" commands that are not supposed to "break" scripts? Does git
only use linux "plumbing" commands? Because if git commands uses linux
"porcelain" then the linux "porcelain" change could cause git to change
(not necessarily "break"). Maybe git-porcelain only uses
linux-porcelain, and git-plumbing only uses linux-plumbing.
Definitely thanks in advance for any replies!
v/r,
neal
On 25.02.2012 01:05, Neal Kreitzinger wrote:
"high-level" question:
If I compile git 1.7.9.2 (from git.git source) on RHEL6 test-box and
test it and conclude that it "works right" is that sufficient for me to
then go ahead and compile git 1.7.9.2 on RHEL5 real-box and
expect/assume that it will also "work right"? IOW, will they produce the
same results? Because if not then I have just potentially broken the
real-box.
Depends on your thoroughness. I.e. you have to assume that your testing
does actually test aspects that are not covered by all the tests
included with git (and not detected by hundreds of other users on that
platform). In that case you can't guarantee anything, even applying
routine security patches to the operating system could potentially break
things (and some companies really test every single patch they apply to
mission-critical systems).
"low-level" question:
I suspect git calls linux commands alot. Git has "plumbing" commands
that are not supposed to "break" scripts. Does linux also have
"plumbing" commands that are not supposed to "break" scripts? Does git
only use linux "plumbing" commands? Because if git commands uses linux
"porcelain" then the linux "porcelain" change could cause git to change
(not necessarily "break"). Maybe git-porcelain only uses
linux-porcelain, and git-plumbing only uses linux-plumbing.
As far as I know there is no plumbing/porcelain distinction in the linux
kernel. But while the internal interfaces in the kernel change a lot,
the external interface (to user space programs like git) is relatively
fixed. You can assume that git is adapted to incompatible changes very
fast. But nobody can guarantee you that bugs won't make a difference
going from one platform to another.