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...)
Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Reply to: