He's not dead, he's resting

Managing Unpackaged Packages, or “What’s this ‘importare’ thing?”

There’s a problem that most Linux distributions don’t solve well: what do you do when there’s no package available for something you want to install? For Gentoo, for example, your options are generally:

  • Installing it by hand. Then, when it comes to upgrading or removing it, realising you’re stuck with either nothing at all or autotools’ broken ‘make uninstall’ support. And realise that your depclean / uninstall-unused is broken unless you add dependencies of that package to world, even if you don’t really care about the dependencies.
  • Whining “how do I get an ebuild for this package that me and two other people use into the tree?” repeatedly until you give up.
  • Writing a really bad (no USE flags, no reliability checking, bad deps and so on) ebuild that works for yourself, and putting it in a local overlay.
  • Spend ages writing a good ebuild, and hopefully putting it into a public overlay where it can be neglected once you realise that you don’t really want the package after all, despite having spent three days installing it.

This is even more of an issue for Exherbo, where one of the stated goals is to avoid having packages for things not used by a lot of people (but this isn’t a problem, as we’ll see).

A similar problem is how to handle manual installs of, say, svn or git packages when there’s no scm ebuild available. Either you spend ages making an scm ebuild (possibly for a one-off bug fix test) or you install outside of the package manager and hope for the best (and cry when you have things depending upon that package).

Paludis provides a different solution: importare. This little toy is a tool for using the package manager to install a package where no ‘package’ (ebuild / exheres / rpm / deb / whatever) is available. Specifically, it provides for:

  • Clean upgrades and uninstalls of the package.
  • Dependency tracking for the package.
  • Ability to use that package to satisfy dependencies of other properly-packaged packages.
  • Querying packages that have been installed that way, including content queries (‘what provides /bin/foo’?)

To use importare, you need an installed-unpackaged repository. You can’t use an existing VDB or Exndbam repository for tracking installed packages because there’s considerable difference metadata-wise between Ebuild or Exheres generated installs and importare-generated installs. A Paludis repository config file would look something like:

format = installed_unpackaged
location = /var/db/paludis/repositories/installed-unpackaged

Then, make an image of what you want to install under some directory. For autotools packages, you can just do make DESTDIR=/path/to/some/tmpdir install. Other build systems provide a similar option.

Install this image using importare --location /path/to/the/tmpdir category-name/package-name version slot, where:

  • category-name/package-name is what you want to call the installed package. If you’re going to use the package to satisfy dependencies, use the same name as the repository package (app-misc/whatever, for example). If not, you might want to use unpackaged/whatever.
  • version is the package version. If unspecified, 0 will be used. You can use scm for scm packages.
  • slot is the package slot. If unspecified, 0 will be used.

Then you can clean up your temporary directory.

One small caveat: Paludis 0.26 doesn’t realise that it should do an install-uninstall rather than just an install if you install to an installed-unpackaged repository when you have an identical package-slot in a vdb or exndbam repository. If you’re replacing something ebuild-installed or exheres-installed with something importare-installed, you’ll have to tell Paludis to uninstall the previous package afterwards.

A few more options:

  • --install-under /foo will install to ROOT/foo rather than ROOT/. This is useful if you’re dealing with packages that are just ‘untar into this directory’.
  • --description can be used to provide a description. This will show up in --query and the like.
  • --build-dependency and --run-dependency can be used to specify dependencies (both can be provided multiple times). The parameter is a standard package dependency string.
  • --preserve-metadata will copy descriptions and dependencies from a previous importare-installed package that is being replaced by this install.

7 responses to “Managing Unpackaged Packages, or “What’s this ‘importare’ thing?”

  1. Pingback: Daniel Lange's blog

  2. Tahiry November 25, 2008 at 2:25 pm

    I have installed texlive 2008 from a CD ISO. And try to have app-text/texlive as a “provided” package. I try to follow this post but I always get this message

    $ importare –location /usr/local/texlive/2008 app-text/texlive 2008
    Building dependency list…
    Dependency error:
    * In program importare –location /usr/local/texlive/2008 app-text/texlive 2008:
    * When performing install action from command line:
    * When executing install task:
    * When building dependency list:
    * When adding PackageDepSpec ‘=app-text/texlive-2008:0::unpackaged’:
    * When adding package ‘app-text/texlive-2008:0::unpackaged’:
    * No suitable destination for ‘app-text/texlive-2008:0::unpackaged’ in (installed) (paludis::NoDestinationError)

    * No unread news items found

    * Searching for configuration files requiring action…
    * No configuration file updates required

    Do you guys have en idea on ow to solve this problem ?



  3. Ciaran McCreesh November 25, 2008 at 2:29 pm

    You’re ignoring the part about making the installed_unpackaged repository.

  4. Tahiry November 25, 2008 at 2:48 pm


    I forgot name it installed_unpackaged instead of installed_unpackaged.conf

    Thanks again.


  5. Pingback: Managing Accounts with the Package Manager « Ciaran McCreesh’s Blag

  6. Dieter_be January 26, 2009 at 9:22 pm

    It looks to me that this is just “building a binary package”. Eg in Arch building a binary package is very simple and very similar to this.
    Or am I missing something?

  7. Ciaran McCreesh January 26, 2009 at 9:27 pm

    There’s a big gap between this and building a binary package. Building a binary package requires extensive dependency checking, writing descriptions, providing homepages, writing post-install scripts and so on — it’s nearly as complicated as making a proper source package. importare is designed to be highly minimal, for those times when you don’t want to put in the effort of managing things properly.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s