5

For example, why can't I run Ubuntu programs on Fedora or Arch, and vice versa? And on the same note, why can't I use apt-get in Fedora or pacman in LFS? And what about .deb and .rpm files? Could someone please explain for a complete Linux novice?

3
  • 3
    You can get pacman in LFS, you just have to build and install it. The LFS docs have a section on building and installing the deb package management systems. Alien is a way to convert from rpm to deb that works sometimes. Not worth posting as an answer, but possibly informative. Dec 8, 2013 at 22:44
  • What about running, say, "Distro XYZ" programs in "Distro ABC"?
    – hkk
    Dec 8, 2013 at 22:47
  • You can sort of. It just takes lots of tweaking. It's about different ways to manage what goes where, dependency chains, and other almost trivial but non-trivial things. Dec 8, 2013 at 22:49

3 Answers 3

7

There are several layers of the problem, mainly:

  1. binary compatibility - software in each distribution is compiled against libraries from that distribution. These may differ in the compiler/compiler flags used for building them and/or selected features. Hence you could hit problems where some pieces of a library from distribution A being not available in the same library in distribution B. Software from A running on B could be looking for something that just isn't there.

  2. package management - you can use several package management systems, but it's bound for troubles, because they don't know about each other. If you use pacman to install X, then rpm on the same system won't know about it. And that's just the beginning - next thing is rpm overwriting some file from a package installed via pacman, thus very likely breaking the package in question and likely something more (see 1.).

    There are some tools that can convert packages from one format to another, but these are often rather useless exactly because of 1.

    A lot also depends on what package manager you stack on top of what. Compiling your own versions on an underlying distribution is fine, you just have to keep track of the installed files yourself. Using advanced package managers on top of LSB is likely to be more problematic, because they might remove/change files for which they think they are free to do so.

6
  • In an LFS system, would it be possible to run Ubuntu programs, since you can get apt-get?
    – hkk
    Dec 8, 2013 at 23:02
  • 1
    @cloudcoder2000, Doesn't LFS compile everything? Use the source!
    – hildred
    Dec 8, 2013 at 23:34
  • @cloudcoder2000 LSB mandates that a system must accept rpm. In debian based distros there is alien for this compliance.
    – jordanm
    Dec 9, 2013 at 5:50
  • @cloudcoder2000 sure it would be possible, I never said it's impossible - there are just quite some obstacles if you want to use it on a larger scale. The more applications from other distributions you decide to use, the more likely you are to get the system screwed.
    – peterph
    Dec 9, 2013 at 21:27
  • @peterph Have any distro/program tried to create cross-distro compatibility? The closest I can think of is packageKit.
    – hkk
    Jan 3, 2014 at 19:36
0

They are all the same programs; it's just a matter of how they're packaged. The biggest reason is simply because you want to have the management of the packages centralized. Each distribution's package manager is not compatible with packages from a different distribution, so to brute force install a package from a different distribution (without converting it) you would have to have multiple package managers managing packages. This causes problems with each one being unaware of which packages the other might be managing. So, you will end up with a lot of conflicts between them.

On the note of using a package manager with LFS, there really isn't much stopping you from using apt, pacman, or yum on top of LFS. I wouldn't recommend it though. It could work if you were to try right now. You could compile Arch Linux's pacman, configure it to use Arch's repositories on top of an LFS system. There is a possibility that it could work if you provided everything in the "base" package. If it works now, there's no guarantee that it will continue to work in the future. You could end up with conflicting and incompatible libraries, major changes to how the filesystem is set up (like Arch's recent move from /var/run to /run). The package maintainers are expecting the system the packages are being installed on to be a certain way, so if you can guarantee that your LFS system will meet those expectations, it should work. It would require a lot of maintenance on your part though.

0

Just to add some small points to peterph's answer

Here I illustrate with a minimal C example how trying to run a program against a library it wasn't compiled against can fail (or not): https://stackoverflow.com/questions/2171177/what-is-an-application-binary-interface-abi/54967743#54967743

The consequence of this is that the only way to ship a reliable cross distro binary is to ship all its library dependencies with it, which is what formats such as snap, flatpak, etc. do. The result is a much larger software package than a distro-specific build, which can rely on native .so dependencies, but it is the only alternative to having distro-specific releases.

Peter does however mention one more issue in passing: you cannot ship multiple versions of certain system components easily like you can ship .so shared libraries. The X server is an example, but perhaps the kernel itself is the most fundamental one.

These are typically runtime components that are running at all times waiting for user input to respond to (server like), and which distros normally only support one of at a time. If an incompatibly with those comes up in those, then it becomes a question of how much you need to visualize to get your software running properly. The extreme case would be "you have to run a full virtual machine like QEMU", but the more you virtualize, the slower things get, so there's a tradeoff.

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.