19

I'm trying to partition my harddisk and install Ubuntu and Debian. So, I have no need no need to preserve any old data. Latest editions of both OSs will be used.

I'm trying to understand how I can install libraries, programs, etc. through apt in Ubuntu and not re-install it on Debian and vice versa. Here, I'm assuming anything that works for Ubuntu will work for Debian, and hopefully vice versa as well.

I know I can share /home. But, that's not where majority of the libs/programs will be. Should I put /usr on a different partition and mount /usr on both OSes? Or maybe I just need to mount /usr/local? Or is there a better way to do it?

dev_nut
  • 299
  • 1
  • 5

3 Answers3

16

Or is there a better way to do it?

  • Install all software you use as snaps.
  • Install all software you use in a partition named /opt/. That is likely to be a source installation (tar.gz).

Those 2 methods of installations can be shared amongst distributions. The last one you will need to add something to PATH or copy a service into the main system.

You can not share /usr/ or /var/ between 2 different installations. You can share /usr/local/ though. 2 distributions can have different versions of libraries, so you may need to install a few libraries on either of those systems. But those few kb you save is not worth the time you are going to spent on this. Plus you are likely to then still break either system.

Rinzwind
  • 299,756
  • This answer actually tries to give me some solutions. When you say you I shouldn't share /usr, shouldn't I do it even with the same ubuntu versions? – dev_nut May 02 '17 at 17:37
  • @dev_nut You should not share /usr/* between two systems; you can share /usr/local/* between the two though you still run the risk of 'local' software not being compatible between the two releases to some level. (so your fstab rules would have /usr/local/* mounted on some other partition, and that would then be shared in both) – Thomas Ward May 02 '17 at 17:38
  • 1
    @dev_nut thing is. 2 different versions of software in 2 operating systems will make one of them crash. Next to that: there might be differences between them in the setup for default users that mess things up (users are in /etc/password) Having the same user with different UID and GUID will be a problem. – Rinzwind May 02 '17 at 17:45
11

The one thing you never do is mix Debian and Ubuntu repositories, system libraries, programs, etc. It will massively break both systems. (This also extends to mixing Ubuntu and non-official variants like Mint; and while you theoretically can mix Kubuntu and Ubuntu for example of 16.04, you just shouldn't and should keep their core systems separate).

Ubuntu is on a much more rapid release cycle with much more updated software libraries than Debian has. The inverse is true as well - Debian doesn't have updated libraries, etc.

Mixing and matching will explode the systems. This is why you do not share libraries with each other.

To do so will break both systems. Do not try and share libraries and programs between the two systems.

While you technically can share user home directories across releases and distributions, you may have odd issues on one or more OSes because of differing versions of configurations by the differing versions of software on each system.

Thomas Ward
  • 74,764
3

One more point I want to add to the existing answer is about apt and dpkg, and how they handle the information about installed softwares.

dpkg, which is the core package management application, uses /var/lib/dpkg/status file to store and retrieve information about debian packages installed in a system. This is very specific about your running. Even a single entry may messed the whole package management thing.

Say for example, You have version 3.18 installed for nautilus in Ubuntu. Then if you share this info, debian will see it has 3.18 for nautilus, even if it has actually 3.16. This is very simplied example. But there can be more complexity. For example, debian may see that you have packages installed from non-existing repository for no good reason and will try to remove those and vice versa.

Rinzwind's answer has illustrated one simple way to work-around with common application i.e. using self-contained applications distributed as snap or flat-pak packages. These aren't sharing libraries but if you wanted something sort of common application that may fulfill your goal.

Anwar
  • 76,649