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...
Thanks!
> 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
mistake.
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