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

Re: Why is utah-glx not in testing ?



Anthony Towns <aj@azure.humbug.org.au> writes:

> On Mon, Jul 02, 2001 at 04:55:41PM -0700, Philippe Troin wrote:
> > I've just found that one of my packages cannot make it to incoming.
> > Here is the update-excuses output:
> >      * utah-glx 0.0-cvs-20010214-1 (new) (optional) (high)
> >           + out of date on m68k: utah-glx (from 0.0-cvs-20001110-1) (but
> >             m68k isn't keeping up, so ignoring this problem)
> >           + there are up to date bins in m68k also
> >           + valid candidate (will be installed unless it's dependent upon
> >             other buggy pkgs)
> > The dependencies are:
> > Depends: xserver, libc6 (>= 2.1.2), xlib6g (>= 3.3.6-4), xfree86-common (<< 4.0) | xserver-common-v3
> 
> Those are the i386 dependencies, there are other architectures too.

Damn, forgot about those...

> In particular, update_output.txt says:
> 
>     utah-glx: m68k: utah-glx
> 
> which says the first arch (alphabetically) where utah-glx causes problems is
> m68k, where it's uninstallable. The m68k dependencies are:
> 
> Depends: xserver, libc6 (>= 2.1.2)
> Recommends: libutahglx1
> Conflicts: xfree86-common(>=4.0)

I disagree...

> But the only "xserver" provider in testing/m68k is xserver-xfree86,
> which Depends: on xfree86-common (>= 4.0).

I agree...

> You'll need to talk to the m68k porters (m68k-build@nocrew.org) about
> getting the new version of utah-glx built to fix up the dependencies on
> that arch. You'll want to do the same thing with the powerpc porters, since
> the version they've built has the same dependencies.

Where do these m68k dependencies come from ?

Let me explain:

 the utah-glx source provides three binary packages:

   - the utah-glx: X server add-on
   - libutahglx1: the GLX enabled mesa library
   - libutahglx-dev: development package for the above.

The X-server extension only makes sense on the alpha and i386
platforms (since the utah-glx supported cards only work on these
platforms), however the libutahglx* libraries are useful on any
platform since they allow encoding GL request on the X connection
(rather than rendering them on the client side).

Hence, from utah-glx's control file:

  Source: utah-glx
  Section: x11
  Priority: optional
  ...
  Package: libutahglx1
  Architecture: any
  ...
  Package: libutahglx-dev
  Architecture: any
  ...
  Package: utah-glx
  Architecture: i386 alpha hurd-i386

And debian/rules takes care of building the utah-glx package only for
i386 alpha and hurd-i386.

So for m68k there is no utah-glx.deb:

  phil@auric:...main/u/utah-glx% /bin/pwd
  /org/ftp.debian.org/ftp/pool/main/u/utah-glx
  phil@auric:...main/u/utah-glx% ls *_m68k.deb
  libutahglx-dev_0.0-cvs-20010214-1_m68k.deb
  libutahglx1_0.0-cvs-20010214-1_m68k.deb

So where do the m68k utah-glx dependencies come from ?

Thanks for helping anyways,
Phil.



Reply to: