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 <[EMAIL PROTECTED]> 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!
