Revision 4 as of 2008-03-02 10:17:59

Clear message

What is a NBS?

NBS stands for "Not Build from Sources". They are binary packages that are no more built from a source package anymore (for example, because they are superseded from a newer version), but are kept in the archive, since a number of packages still depends on them.

An appreciated activity involving NBS is to rebuild packages that depends on them, so that the NBS has no more reverse dependencies on it and can be removed from the archives. Frequently, a rebuild will cause a selection of new binary dependencies, and the package will work, although sometimes adjusting debian/control is needed, and more rarely, one needs to port the package to work with the new system.

A list of NBS is available at [http://people.ubuntu.com/~ubuntu-archive/NBS/] and updated every ~6 hours. For each package that NBS, the list of packages that depends on the NBS and needs to be ported is provided. Once everything is confirmed as ported (and the list reaches 0 packages), the NBS can be removed from the archive, making everything cleaner.

Example 1: libminc0

libminc0 is a NBS superseded by libminc2-1 in Hardy. The ~ubuntu-archive/NBS/ page reports that one package still depends on libminc0:

-- hardy/universe sparc deps on libminc0:

In this case, we need to rebuild minc-tools against libminc2-1 to remove libminc0 from the archive.

First of all, we need to find the source package that builds minc-tools. We can use [http://packages.ubuntu.com/] or apt-cache :

apt-cache showsrc minc-tools | grep Package
Package: minc

What we have to do now is download the minc source package and check how to rebuild the binary package minc-tools wth the new library. The debian/control file shows:

Depends: ${shlibs:Depends}, csh | c-shell, netcdf-bin, libgetopt-tabular-perl, libtext-format-perl, imagemagick

This means that the dependency is not hardcoded in it, and is automatically chosen at build-time.

Let's modify the debian/changelog file. Last changelog entry is

minc (2.0.14-2) unstable; urgency=low

Since Ubuntu didn't made any change to the package, we just add build1 to the current version and a good description for the transition we are doing:

minc (2.0.14-2build1) hardy; urgency=low

  * Rebuild for libminc0 -> libminc2-1 transition.

 -- Name Surname <email@ubuntu.com>  Sun, 2 Mar 2008 10:55:10 +0100

Add a (LP: #XXXXXX) tag to automagically close a bug in case it has been reported yet.

Since this is a no-change rebuild, we do not modify the Maintainer field in debian/control.

Now, a test build is needed to check that the package doesn't FTFBS with the new library. Once the build-install-run test is successfull, we can upload the package (or create a debdiff for sponsoring).

Example 2: libmpich1.0c2

libmpich1.0c2 is a NBS superseded by libmpich1.0ldbl. These packages still depends on libmpich1.0c2:

-- hardy/universe amd64 deps on libmpich1.0c2:
-- hardy/universe i386 deps on libmpich1.0c2:
-- hardy/universe sparc deps on libmpich1.0c2:

In this case, we have three binary packages to inspect: illuminator-demo, libluminate7, and libpetsc2.3.2. Looking at a hardy cache, we can discover that those come from two sources: illuminator and petsc.

apt-cache showsrc petsc | grep Binary shows:

$ apt-cache showsrc petsc | grep Binary
Binary: libpetsc2.3.3-dbg, libpetsc2.3.3-dev, petsc-dev, petsc2.3.3-doc, libpetsc2.3.3

Our reverse dependency for petsc is libpetsc2.3.2, which means we don't really care, as the new source doesn't use it, but we need to NBS libpetsc2.3.2 before we can NBS libmpich1.0c2

Next step is to inspect the binary packages to see if they have alternatives defined in the dependencies. In this case, there are hard-dependencies for libmpich1.0c2 for both illuminator-demo and libluminate7.

Next thing to try is a rebuild. Update the changelog with a <version>-<debian>build1 entry, and report the transition you are processing in a form like:

  * rebuild for libmpich1.0c2 -> libmpich1.0ldbl and libpetsc2.3.2 -> libpetsc2.3.3

Don't touch any other files in the package, generate a new source candidate, and try a test build.

If the package rebuilds fine, the transition is complete. Sometimes, anyway, the transition brings to a FTFBS that must be tackled and fixed before the NBS can be removed from the archive.


  • Once reverse dependencies from the NBS list are zeroed, announcing that on #ubuntu-devel would be greatly appreciated, so that an archive-admin can remove the NBS.
  • http://people.ubuntu.com/~ubuntu-archive/NBS/ is updated roughly every 6 hours, but it gets stuck sometimes. Complain on #ubuntu-devel if it hasn't been updated for a long time (but first check the archives to make sure).

  • Sometimes one NBS package will depend on another, which can confuse a transition.
  • In case a package has an alternate dependency, it will still show (but doesn't always need fixing).
  • Remember that NBS removals are manual, which can confuse the results.