2

I have non-root access to a grid of computers. The installed OS is the following:

$ uname -mrs
Linux 2.6.18-274.el5xen x86_64

$ cat /etc/*-release                                                                                                      
Scientific Linux SL release 5.1 (Boron)

I built the latest version of core utils locally with

./configure --prefix=<some_path>
make
make install

but before adding this new install to my PATH & LD_LIBRARY_PATH, I'm reluctant to start using a version of core utils that may not be compatible or safe to use with my OS.

I know that one answer is "test and see if it works", but I would prefer to make sure that I will not run into problems later when doing real work with core utils (e.g. moving/deleting files, using chmod, etc.)

Is this a legitimate concern? Are core utils fully backwards compatible with versions of GNU/Linux this old? How do I find out?

  • 1
    I'd be really really really surprised if there is a problem here. For starters, you haven't changed the libraries that the core utils are linked to, and the build process mostly confirms that there is no compatibility problem with that. GNU core-utils are portable -- they are not just intended for use on linux -- and so which kernel you use should not matter. – goldilocks Jul 16 '13 at 14:28
2

As long as the system calls exist within the kernel itself, the version of coreutils in use doesn't matter. And coreutils doesn't use any exotic (for Linux) system calls, so you aren't likely to run into any incompatible utilities.

Having said that, grab the SRPM, replace the tarball inside, rebuild it, and use that instead.

  • Thanks @Ignacio. When you said "grab the SRPM, replace the tarball, etc..", I am not familiar with that process (happy to start another thread if necessary). Is this something I can do without root privileges? – Amelio Vazquez-Reina Jul 16 '13 at 14:00
  • 1
    Most of it you can do without root. The final installing part not so much. – Ignacio Vazquez-Abrams Jul 16 '13 at 14:04
2

It's hard to know and you can't get any guarantee. For instance, at some point, some versions of GNU head/tail stopped supporting head -1 (the deprecated variant of head -n 1) causing many scripts to break (they were restored later on).

You'll find that some deprecated options have been removed. For instance GNU touch doesn't have a --file option anymore. Generally, it would be unlikely for those to have been used but you'll never know until you run into the problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.