paradigm
commented
6 years ago Good job hunting down that issue! It would have taken me a while to realize the problem in your shoes. I would have expected git to return non-zero and abort when it saw the unrecognized --branch flag, returning a non-zero that make should have picked up. Maybe I piped something and lost the return value?
I'll make a note about this in the guide somewhere, probably over the weekend.
A few other thoughts:
I expect you're well aware of this, but I feel obligated to warn you that Fedora 14 is no longer supported and is not getting security updates. Maybe try CentOS 6? Age wise it is roughly comparable to Fedora 14, and it largely has the same Red Hat platform specifics. I figure odds aren't bad it'll similarly support your laptop. Unlike Fedora 14, CentOS 6 is expected to continue to get security updates for the next few years. That having been said, Linux is typically pretty good about backwards compatibility; whatever makes you feel obligated to use specially Fedora 14 is likely something unusual and I can't say with any certainty that any other major distro supports it.
Bedrock Linux lets you have multiple instances of a lot of things, like libc, at once, which is part of how it lets you run software from multiple distros simultaneously. However, there are some things it can only have one instance of at a time, such as the kernel. If some executable from some other distro has a hard dependency on a given kernel feature that the Fedora 14 kernel does not support, Bedrock Linux is unable to help you run it. For example, I think Void Linux's xbps package manager uses a relatively new system call and likely won't work for you with that older kernel. Most things aren't that picky about the kernel version, and so you should be fine, but it's worth keeping this in mind if you run into a problem.
Other than one security related feature that requires Linux 2.6.24 (which is older than Fedora 14's 2.6.35, so you're okay there), I try to avoid having Bedrock Linux require some overly new kernel feature, prioritizing portability, and so it probably works with Fedora 14's kernel. However, that kernel is a bit older than anything I've personally tried, and I might have added a dependency on something newer without realizing it. Probably won't be an issue, but it's also worth keeping in mind.
Bedrock Linux has some rough edges and isn't quite right for everyone at this stage, but your situation - the need for old packages with a desire for newer ones - is a very good use case for Bedrock Linux. Hope this works out for you. If you run into other issues, don't hesitate to ask for help.
James-E-A
I'm trying to use Bedrock Linux so I can combine Fedora 14's support for my laptop's graphics chipset with more up-to-date browser, tools, etc.
However, it seems that the feature to retrieve a specific tag with
clone --branch <tagname>was added at some point between git 1.7.9.5 and 1.8.3.5. I couldn't spot the exact place in the changelog, though I managed to get my hands on a Git 1.8.2.1 binary, which did work for me as-is and seemed to be able to just get dumped into/usr/local/binwithout breaking anything.The fetch system's expectation of this behavior breaks when presented with an old Git version (e.g., Fedora's 1.7.4.4, which cannot trivially be updated to a newer version due to its requiring Perl to be updated, etc etc), since it's not cloning the right version of
libattr. Could it be added to the install guides, something like "Git (1.8+ recommended)? The error was not obviously attributable to the Git version; it seemed to be a problem with libattr:include/xattr.his just missing in the Git master, evidently..(and ninja'ing it in with(until cp -v /tmp/xattr.h src/libattr/include/xattr.h; do sleep .1;done) & makedoesn't fix the compiler error :rofl:)