Newbie Distro Question 1: Reasons for inter-distro pkg incompatibility.
 

I'm planning to dive into linux and need to choose a distro. Before I do, I'm trying to figure out a few basic things.
For example, people often seem to tout distributions based upon the pkg manager with which they come.
But that's just a program, and they should be able to run on various distributions.
It seems that apt and synaptic, for example, do run on suse. YAST, however, may not run on ubuntu.
From my newbie, ignorant point of view, there would seem to be three possible reasons for this:
1. The pkg mgr in one distribution expects to find things in a given place in the file structure, but they're in different places in the different file structures of various distributions. Is this wrong?
2. Distributions come with libraries that differ in key ways. But couldn't one just add additional libraries from the other distribution and then be able to run its programs?
3. Deeper differences that make the basic distributions (slackware, debian, etc.) more fundamentally different than I am taking into account here.
Thanks in advance for explanations!

All of the above :)

And let's rephrase 1) -

A "package manager" is essentially a database (of programs and program dependencies) and the tools to manage this database (apt-get, yum, rpm, dpkg, synaptic, etc etc). So yes, a dpkg download will be incompatible with an rpm download (for example).

And guess what: the situtation is *exactly* the same for *any* package manager. Including Windows. Win9x did things differently from Win/XP, .msi does things differently from SSMS; sometimes you write to an .ini file under \windows; sometimes you write to the registry, in .Net you write to an XML assembly configure.

Trying to "make things easy" inevitably complicates things ;)

You can always avoid package managers altogether by simply building from source ;)

Short answer: All three together.

On 2. That is what we do - but it is only useful in limited circumstances ... eg. to run a 32 bit app in a 64 bit distro involves installing the 32bit libs et al in a non-standard location then telling the app where to find them; also sometimes we want two different versions of gcc ... in which case we change the name of the executable and its libs so the other gcc doesn't get confused.

Its not something that gets automated.

Bottom line: you can do anything you have the expertise and time for. It is technically possible to work out how to use each distros repos in each other - its just that there is no point. If one distro has a package not available in yours, you install from the source code.

You see ... gnu/linux is (almost all) free software - one of the things this means is that you have access to the source code and the ability to change it to suit you. This changes everything.

That's just like asking why there can't be just one distro.

You just choose the system you like!

Even more - one cannot expect a Debian deb to install to Ubuntu or a SUSE rpm to work in fedora.

This is because each binary package is compiled against other packages in the same distro - and the distro maintainers will have different build policies; use different releases, different patches, different compile options etc. Thus each distro is fundamentally different.

In fact, without a package manager, we used to have this thing we called "dependency hell". <gibber>

But isn't backwards compatibility a Linux principle? In which case later releases would solve such problems?

Which raises another question - I often see it written that a given distribution comes with later releases of certain programs.
Does the threat of 'dependency hell' mean that you couldn't just go to the developers' sites & download the latest versions?

Almost.
But I'm not asking why there can't be just one distro.
I'm trying to get a handle upon the nature, parameters, and seriousness ('depth') of the differences.

And among other things - of what makes programs included in them incompatible or only partially compatible with other distributions.

In addition to the building-from-source option, could one have several pkg mgrs to handle dpkgs, rpms, etc.? Or would that create problems (inconsistent databases of what's where in your system)?

Because you have source code available, yes it is entirely feasible to patch software for forward and backward compatibility. While the linux kernel does generally go backwards, things inevitably get deprecated eventually. Further you can not confuse the linux kernel with all of the other utilities (GNU in large part) as well as the other software that makes up a "linux" distribution. Frequently a certain way of doing things just hits the wall and things get rewritten entirely. A good example of this is KDE which is one of the most popular Desktop Environments in the world of gnu/linux.
http://www.linuxjournal.com/content/...rt-did-it-work

That link ought to give a simplified example of what I'm talking about. In relation to package managers, why would you need the trouble of making one distro's package manager work on another? You would simply use the one supported by the distro and as mentioned above in the cases where no package is available for your distro then you just install from source. You can go a long way towards avoiding this scenario by choosing a distro that uses .deb and RPM packages. My distro of choice (Slackware) doesn't really have "official" repositories outside of what's available from the installation disk, rather there are a few privately maintained package repositories as well as some popular build script repositories that take the source, compile and package it into the supported package type. Most people consider that primitive whereas many Slackers consider that a powerful feature.

And for Slackware we have src2pkg, which can convert .deb and RPM packages to Slackware packages.
http://distro.ibiblio.org/pub/linux/...html/intro.htm

So much for "no package management."

Yeah, people who say that about Slack have either never used it, or not used it since 1995.

That might work but it's probably a really bad idea, because each package manager has its own separate database, and each package managers will not know about programs installed using another, which is very important for resolving dependencies.

But anyway, you very rarely need to download a .rpm, .deb, etc. to manually install. Most package managers automatically find the package in the distro's repository and downloads and installs it automaticaly.

I have the impression that we are talking about a problem that does not exist....

Given that the top distros all have reasonably complete selections of SW, AND the fact that you can always install SW outside of your distro's package management system, there is no reason for compatibility between distros.

Did you ever install Chevrolet parts in your Ford because what you wanted was not available from Ford or a 3rd-party supplier?

Event the best case scenario - it works - will slowly make a mess out of your system. It is one of the functions of a package manager to prevent that. So, when you compile from source you better create your own package (for THE package manager) and install it.

Since sooner or later you will compile from source, it is a good idea to include package creation tools into consideration when choosing a distro.