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

Re: please build XFree86 4.3.0 for experimental

On Sun, Nov 02, 2003 at 09:39:23PM -0500, Adam C Powell IV wrote:
> Okay, finally finished building this morning (various difficulties), and
> installed successfully; just uploaded.  Sorry about the delay.
> And good news, it even seems to work!  But I haven't pushed it yet...


> The new problem with 4.3.0 is the versioned dependency of xlibs on
> xlibs-data.  So there is a problem if new tetex or xcursor source is
> uploaded between the upload of xlibs-data and xlibs.

...because the arch-independent packages are available from the archive
for your architecture before that architecture has built the
corresponding arch-specific packages, right?

> If, say, MIPS is slow to build xfree86, then tetex/xcursor will be
> impossible to autobuild in the meantime, because xlibs-dev will be
> impossible to install.  And then, if a new X is uploaded before this
> is resolved, neither one can be built because neither is installable.

I see.

> Even worse, autobuilding X becomes totally impossible once xlibs-data is
> accepted, because to build it, one must install libxcursor-dev, which
> requires installing xlibs, which is not installable because it is old
> and xlibs-data is new.  So one must have previously installed either
> xlibs 4.2.x or else *both* the old xlibs *and* old xlibs-data, then one
> can install libxcursor-dev, then one can build the new X.  Or one could
> have previously installed libxcursor-dev and tetex-bin (which is why I
> didn't notice this wrt tetex), but the autobuilders of course have none
> of these.

I see.

> There are two ways to resolve this: break the dependency of libxcursor1
> on xlibs (or change it to "Recommends" or "Suggests"), or soften the
> version requirement of the dependency relationship between xlibs and
> xlibs-data (e.g. ">= 4.3.0" or even ">=${Source-Version}" will solve
> this problem, though it may break in other subtle ways).

No, I think the right thing to do is soften the versioned dep on
xlibs-data.  In fact, the versioning can go away entirely since it did
not exist before 4.3.0.  Should the data ever change in a way that
matters for compatibility, versioning can be added.

I'm not sure if it was Daniel Stone or me who decided to make xlibs-data
and xlibs upgrade in precise lockstep, but it is starting to look like a

Thanks for the patient explanation.  You were describing a situation I
was familiar with (I don't have an i386, so on my sparc and powerpc
boxen I often see locales and glibc-doc update one day, and the rest
glibc the next).  I hadn't previously thought about what this can do to
-dev packages and autobuilders before.

G. Branden Robinson                |     Human beings rarely imagine a god
Debian GNU/Linux                   |     that behaves any better than a
branden@debian.org                 |     spoiled child.
http://people.debian.org/~branden/ |     -- Robert Heinlein

Attachment: signature.asc
Description: Digital signature

Reply to: