Find the answer to your Linux question:
Results 1 to 6 of 6
So I've had this idea concerning how to run software across multiple different debian-type OSs. Why: I like the stability of Debian stable, but the software is ancient. Firefox 3.5? ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined! spaceminer143's Avatar
    Join Date
    Nov 2008
    Posts
    20

    Universal .deb Installation Ideas


    So I've had this idea concerning how to run software across multiple different debian-type OSs.

    Why:
    I like the stability of Debian stable, but the software is ancient. Firefox 3.5? So either I upgrade to an OS that I like less or else I spend a lot of time getting software to run. Neither is that difficult but neither is optimal either.

    What:
    Debian Stable has a thing called 'backports' which is where newer versions of software are compiled and linked statically and distributed as binaries. There is only one real downside: someone has to compile them. Of the several major software applications that I most wanted to upgrade, only one of five a backport. Sure, I could break down and just compile my own software, but the next time I want a new version of a different program I have to do it again.

    Gory details:
    My idea is really simple: you have essentially another package management program in addition to the one used by the OS, which instead of installing apps for your OS installs them in a different directory for a different OS, including all dependencies. Using firefox as an example, your directory structure might look like:

    Code:
    /
        -> usr
             ->bin
                firefox
            ->firefox
                (firefox settings, files, etc)
            ->lib
                (firefox libs)
        ->UBUNTU_1104
             -> usr
                 ->bin
                     firefox (run_script)
                 ->executables
                     firefox
                 ->firefox
                     (firefox settings, files, etc)
                 ->lib
                     (firefox libs)
    So in this example the user has an application, firefox, which he has an old version corresponding to debian stable installed as normal in his /usr/bin directory, and he can run it just as normal. However, he also has a version corresponding to ubuntu 11.04 (I didn't pick this for any particular reason) installed, including all dependancies in the /usr/UBUNTU_1104. To launch this other version of firefox the user calls the run script in the /usr/UBUNTU_1104/usr/bin, directory, which sets up the environment correctly- I'm really not an expert in all this but I assume you could just set LD_LIBRARY_PATH to point to the needed libraries in /usr/UBUNTU_1104/usr/lib. Is it possible that the application would need to chroot or something to where /usr/UBUNTU_1104 is viewed as /, if it references a bunch of absolute paths in /etc or something? You'd have to install a lot of libraries twice of course, but you have to do that for a statically linked binary as well, essentially. If you wanted to get fancy you could make the libraries just links to other libraries if the correct versions were already installed (say you have some apps from debian testing and some for an ubuntu release). The beauty of this plan is that it would be work just as well for 200 programs as for 2, and you'd be able to install any debian type OS applications. People already put a lot of time optimizing these packages to run together and making the package manager handle dependencies correctly, so why should the work have to be done twice?

    Closing:
    I'd like people experienced with debian/ubuntu package management to point out problems, or if there are good points, noting those would be appreciated too. How difficult to implement does this sound- am I missing something here? Normal users: if something like this existed, would you use it? Why or why not?

  2. #2
    Administrator jayd512's Avatar
    Join Date
    Feb 2008
    Location
    Kentucky
    Posts
    5,023
    The base of your idea has a lot of merit, but you already pointed out what I think would be the major issue. Installing multiple instances/versions of libraries.
    While manually doing so for one or two specific programs won't cause any issues, having it done for 20 or 30 most likely will end up causing conflicts with applications that you never intended to influence.

    I think it would be like having yum and apt-get running on the same system.

    I'm not an expert on the ins and outs of package managers, so those are just my thoughts.
    Jay

    New users, read this first.
    New Member FAQ
    Registered Linux User #463940
    I do not respond to private messages asking for Linux help. Please keep it on the public boards.

  3. #3
    Just Joined! spaceminer143's Avatar
    Join Date
    Nov 2008
    Posts
    20
    I understand what you're saying, but you're at least missing something, although I may be as well. As I understand it libraries are linked at runtime by the dynamic linker, ld.so. ld.so knows where to look for libraries based on an environment variable, LD_LIBRARY_PATH.
    So for your debian applications, you'd set it to all the normal locations, /lib, /usr/lib, or wherever libraries are normally stored, and for your ubuntu applications you'd set it to /usr/UBUNTU_1104/lib, /usr/UBUNTU_1104/usr/lib, or whatever. So you would essentially have two different systems managed by apt, completely separate.
    You'd have to have to only manage one or the other at a time, but they would never have to interfere with each other. They'd each have their own sources.list, corresponding to the sources for their respective OS, their own list of installed packages, and they'd do dependency resolution only for their specific OS, ignoring whatever belonged to other ones.

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Enthusiast sgosnell's Avatar
    Join Date
    Oct 2010
    Location
    Baja Oklahoma
    Posts
    507
    Depending on the package, it's possible to just download an archive and extract it to any folder and run it. Firefox/Iceweasel works that way very well. You can just download the archive, extract it to a folder in your /home hierarchy, and run it. All the necessary libraries are there. This works for all Mozilla packages I'm aware of, and for many others, but certainly not every available package. The standard locations in the root hierarchy to put third-party packages is /usr/local or /opt. You can try that, but I would first try just extracting an archive to a folder in /home and see if it runs. If it does, you're done, other than making a shortcut somewhere if you want.

  6. #5
    Just Joined! spaceminer143's Avatar
    Join Date
    Nov 2008
    Posts
    20
    I did not know that. Thanks for the tip.

    It still doesn't work for anything with an external dependency on a library newer than the one in you OSs repository though, right?

  7. #6
    Linux Enthusiast sgosnell's Avatar
    Join Date
    Oct 2010
    Location
    Baja Oklahoma
    Posts
    507
    Yes, a package with external dependencies may not run at all installed that way. Mozilla packages all the necessary libraries in the distribution, but that's actually somewhat rare. All I can suggest is try it and see if it works. If not, you'll have to try something else.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •