Re: Build problem Gtk2-1.037

[Thierry Vignaud <tvignaud mandrakesoft com>]

Ross McFarland <rwmcfa1 neces com> writes:

> > I found the development packages, and installed them. Compile and
> > install were successful, but some of the Mandrake utilities that
> > use Gtk2-perl won't work anymore.
>
> in an older version of mandrake

we're still doing that way.

> the version of the gtk2-perl modules had some non-trivial patches

these patches do be trivial

> to get it to work with some of their tools.

one shot exception handlers are just insane in big apps.
do you expect us to set us an handler that manage all kind of
exceptions on every callbacks?
this is a totally insane policy.
you want exception throwed from callbacks to go up until sg care about
them.
you do not want every piece of code to deal with thousands of possible
problems totally unrelated to what they do and which they do not know
what do to do about.

> there was a lengthy discussion between mandrake and gtk2-perl about
> this that lead to solutions of the issues, but not the way the
> mandrake patches did (because the solutions weren't valid and could
> cause bad juju, jumping main loops.) at any rate, it would appear
> that you are using a version of mandrake with the patched Gtk2-Perl.

our solution did fix quite some issues like gratuitous ERRSV clobberin
and the like that i'd to send fixes again.

> i thought there was a faq entry about this, but apparently there's
> not.  there is some discussion of it on the mailing list if you
> search on google for "site:mail.gnome.org gtk2-perl mandrake" it
> should be in there somewhere. basically you can probably fix things
> by re-installing the original mandrake packages and then installing
> gtk2-perl to a non-system location. (take a look at the comments in
> Makefile in the top-level of gtk2-perl-xs in cvs for some hints as
> to how)
> as a side note this is really Mandrakes fault (and almost all other
> dists do similar things) they should really have private installs of
> any modules like this specifically for their tools so that if a user
> wants to upgrade there's no chance of breaking the tools. redhat and
> pygtk are another occurance of this problem.

so, if someone update libc4 to libc5 on any old libc4 distro, the
resulting breakage is the distro fault?

bullshit.


we patched perl-Glib and perl-Gtk2 b/c we do think that exceptions are
a good error handling system that fit well call-back based GUIes.

you do not think so b/c our solution only cover gtk+ apps not glib
ones (though i'm not aware of a single perl app using perl-Glib but
not perl-Gtk2).

you choose to ignore all errors by default which is an insane policy
as far as i'm concerned.

we provide a patched perl-Gtk2 that works with *BOTH* your one-shot
exception managent and our throwing exceptions scheme.

we patch quite a lot of packages b/c of bugs, missing features,
security issues, ...

one can manually overwrite these with upstream releases and if he
shots itself in the foot, it's his problem.
this can happen with any package (kernel, glibc, kde, ...).

packaging exists for some good reason.

sane upgrade is to update package, not to gratuitously overwriting it
with manuall tarball rebuild.