Re: Woody source frustration!
First, thank you for ccing me in your reply. It seems the subscription system is
broken, it hasn't processed my "subscribe" request sent over eight hours ago.
Christian Marillat wrote:
> >>>> "ACPI" == Adam C Powell IV <hazelsct@mit.edu> writes:
>
> ACPI> * Not closing bugs when they're fixed (e.g. when my suggested
> ACPI> build-depends are added). I had to close 75628 (oaf) myself, and
> ACPI> 75635 (gnome-print), 75636 (gnumeric) and 75637 (libole2) remain
> ^^^^^
> I've fixed this bug in the 0.24-0.1 (NMU)
Yes, thank you very much, I noticed. But the bug was never closed, so I had to
get the source package to see the fix (instead of being notified about the bug
closure).
> ACPI> * Uploading packages with unmet build dependencies. gtkhtml depends
> ACPI> on libcapplet >= 1.3.0, which doesn't exist.
>
> Fixed in the 0.7 release who doesn't compile withe the latest gnome-print
Right. So why update gnome-print if it breaks gtkhtml-0.7? This is exactly my
point.
> ACPI> * Building packages for i386 (and perhaps alpha) then uploading new
> ACPI> dependencies which break new attempts to build. gtkhtml 0.6.1
> ACPI> building is broken by bonobo 0.26 or later, so there is no gtkhtml
> ACPI> for any arch outside of i386 and alpha, and there will be none
> ACPI> until a new gtkhtml is uploaded.
>
> See above.
Right, as before, you uploaded a new package that broke an existing one. I'm not
sure I see the logic there.
> ACPI> * Inconsistent uploading frequency. Things like bonobo and gnome-vfs
> ACPI> are updated within a couple of days of new upstream releases,
> ACPI> gtkhtml hasn't been updated since 0.7's October 19th release- over
> ACPI> a month ago.
>
> See above.
Uh, I'm not sure I follow here. You allow gtkhtml to sit broken while updating
other packages, because the newer versions of other packages break gtkhtml even
further? This is a part of my point about the inconsistency: e.g. gnome-print is
rapidly packaged with each new upstream release (though it shouldn't be because
it breaks gtkhtml), but gtkhtml not in well over a month (though it should be
since it allows you to safely upload the new bonobo- and is needed to build a
1.2.x gnome-core).
> ACPI> * Circular source dependencies!! Can you believe: gnome-core depends
> ACPI> on gtkhtml, gtkhtml depends on control-center, control-center
> ACPI> depends on gnome-core!
>
> Nothing depends on gtkhtml (I've all the Gnome stuff installed)
Uh, yes it does (look at the gnome-core Build-Depends, and configure.in). Could
it be that the package was built without libgtkhtml-dev installed, so the part
depending on it was not built? Or is this an extraneous dependency (in one of
the few GNOME packages whose Build-Depends I didn't write :-)?
Okay, here's the source of the dependency:
gnome-core-1.2.4/help-browser/Makefile.am looks like it builds an "enhanced" help
browser with libgtkhtml-dev installed. Thus while not a *requirement*, it is
(and should be) a *dependency* for a feature-complete gnome-core package (and it
seems from your demonstration that the current i386 binary is not
feature-complete). Note the continued state of breakage: none of the
autobuilders will build gnome-core for any other architectures until this
dependency is satisfied, and this has been the case for well over a month now.
The gnome-control-center (binary package) dependency on gnome-core completes the
circular dependency, which is a bad thing. Maybe this is an upstream problem,
analogous to having rscheme in the Build-Depends of rscheme, so architectures
without 0.7.2 have no hope of ever building 0.7.3 (though this has nothing to do
with GNOME, just another illustration of problematic packaging).
As a temporary workaround, I'll try building gnome-core without gtkhtml, so I at
least have a functioning desktop.
Thanks for the feedback.
-Adam P.
Welcome to the best software in the world today cafe!
Reply to: