[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libgtkmm missing from ppc potato?

"BCM" == Bradley C Midgley <bcmidgle@sanluis.uccs.edu>

   BCM> is it still missing? i am using -unstable but i thought i
   BCM> would see it show up either way.

Yes, it's still missing.  There's no libgtkmm package for PowerPC
in woody *at all*.  There is a libgtkmm-dev, version 1.0.3-1.1,
but nothing newer.

Just to make it a little more fun, the newest version in *source*
form is 1.2.3-1.  I built 1.2.0-1 myself sometime ago.

   BCM> these are all the packages missing (i've noticed) that are
   BCM> causing trouble with unsatisfied dependencies...

   BCM> libgnome-dev gnome-print libgcj0-dev | libgcj-dev libgtkmm

There are more than just these missing, I suspect.  In any case,
poking around a bit shows the following status for the packages
you mentioned:

  Package              Binary       Source      Explanation
  gnome-print          none         none        Renamed to
  libgnomeprint6       none         0.20-1      No Build-Depends line      
  libgnomeprint6-dev   none         0.20-1      No Build-Depends line      
  libgcj-dev           none         none        Renamed to
  libgcj0-dev          none         2.95.1-5    Hung up with gcc upgrade?  
  libgnome-dev         -- no such thing --                                 
  libgtkmm             none         1.2.3-1     No Build-Depends line      

   BCM> is there something i'm missing? is there something i can
   BCM> do to help with this?

libgcj0-dev is probably held up because of the whole glibc/gcc
upgrade thing we're in the middle of.  You might have to wait on
that a bit (although you might be able to build it yourself.

Most of the missing packages seem to be related to missing or
incorrect Build-Depends lines in the control files for the
packages.  Most Debian developers have x86 machines, and upload
binary packages for x86 along with source.  People with SPARCs,
ARMs, m68k, PowerPC, and Alpha machines have to wait until their
architecture-specific build-daemon picks up the source, builds a
binary package, and uploads that binary package to the archives.

The build-daemon machines cannot have every possible support
package installed at the same time for several reasons:

  * There are a huge number of packages, requiring large amounts
    of disk space

  * Many packages are only needed for building one or two other
    packages, which means that having them installed all the time
    is wasteful

  * Some of these packages conflict with one another, making it
    impossible to have everything installed at the same time

In order to make sure that the build-daemon systems have all the
necessary support files to build a particular package, the
build-daemon software looks for a ``Build-Depends'' line in the
debian/control file included with the package source.

If that line is missing or inaccurate, the build-daemon cannot
fetch (or build) and install all of the necessary support
packages, which means that it cannot build some packages.

As for what you can do, well, if you want the packages *now*, you
can try downloading the source and building them yourself.  Doing
so is really easy if you already have all the necessary
build-dependencies installed, and if you've done much compiling of
free or open-source software, it's not that hard to figure out
what additional packages you need.

Even better, if you take the time to build the packages yourself,
and track down the missing dependencies, you can file a bug
against the problem packages so that the maintainer can add the
correct Build-Depends line.  Once the Build-Depends line is in
every package, the build-daemon should be able to keep everything
up to date without (much) human intervention.

(Note that the case of the field name is important -- some
packages currently have ``Build-depends'' lines, which can tell a
human what support packages they need, but are no help to the
build-daemons, which look specifically for ``Build-Depends''.  Any
package with the wrong case should have a bug filed against it,

The major breakage that did exist seems to be fixed now (libglade
conflicting with bonobo), leaving us with the Build-Depends
problem to contend with.  But fixing that problem is very doable
-- it just takes some time and effort.


 Behind the counter a boy with a shaven head stared vacantly into space, 
 a dozen spikes of microsoft protruding from the socket behind his ear.
   C.M. Connelly               c@eskimo.com                   SHC, DS

Reply to: