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

Re: please build XFree86 4.3.0 for experimental

On Fri, 2003-10-31 at 16:15, Branden Robinson wrote:
> On Fri, Oct 31, 2003 at 07:54:08AM -0500, Adam C Powell IV wrote:
> > Is anyone building -0pre1v4?  If not I've got a build going and can
> > upload when it's done.  (Tried to install -0pre1v3 last night, but
> > xlibs-data is only -0pre1v4.)
> I would very much like to see an ARM upload of -0pre1v4.

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...

> > Also, I noticed two problem along the way.  First, there seems to be a
> > circular dependency here.  xfree86 needs libxcursor-dev to build.  But
> > libxcursor1 depends on xlibs.  So one needs xlibs-dev 4.2.x installed in
> > order to build xcursor, though when xfree86 4.3.0 goes into unstable,
> > there will be no xlibs-dev 4.2.x.  Long-term, any release of xcursor
> > while xfree86 is building (and thus is uninstallable on some arches)
> > breaks stuff, so IMO this is a serious bug.
> Unless I'm misunderstaning you, this is no different from the
> build-dependency loop between tetex-base and xfree86.
> (TeTeX depends on Xlib for xdvi, and XFree86 depends on TeTeX to
> generate docs.)

You're right, I hadn't thought of that.

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.  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.

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.

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).

> > I broke the circular dep manually by forcing libxcursor1 to install
> > though xlibs was not configured (wouldn't configure without xlibs-data
> > at the same version).  But the only sane long-term workaround I can
> > think of is to remove the dependency between libxcursor1 and xlibs, and
> > just let applications depend on both shlib packages.
> I don't understand.

See above.

> > Second, xlibs-data asks manually if I want to accept new versions of
> > *all* of its config files the first time it's installed.  I'm not sure
> > about what can be done about this, since those files seem to be moving
> > from one package to another, but it's a bit annoying...
> xfree86 (4.3.0-0pre1v5) experimental; urgency=low
> [...]
>   * Update xlibs and xlibs-data's package descriptions to clarify that X
>     Keyboard Extension (XKB) data is in xlibs, but other
>     architecture-independent data is in xlibs-data.  The XKB data has not
>     moved because dpkg supports no mechanism for migrating conffiles between
>     packages, and it is unacceptable for people to be spuriously shown dpkg's
>     changed-conffile prompt dozens of times when upgrading from versions of
>     xlibs prior to 4.3.0.
>     - debian/control
> -0pre1v5 isn't released yet, but the above change has already been made.

Thank you, this helps a lot!  It would be much better of course if dpkg
could migrate conffiles, but that sounds like a lot of work...

Now ARM folk, any chance of some help with 212569?  (my Tuesday post
about Mozilla regxpcom/regchrome and C++ on our beloved platform...)

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!

Reply to: