Re: Build problem Gtk2-1.037

[Ross McFarland <rwmcfa1 neces com>]

On Mon, 2004-03-01 at 10:49, Thierry Vignaud wrote:
> 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.

then there should be a custom/private install of Glib/Gtk2 for those
apps that expect the non-standard behavior so that users can upgrade
Glib/Gtk2 if they like without issue.

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

the patches are small, but what they change is not trivial. if i recall
correctly the patches would allow for zombie main loops b/c of jumping
over main loop boundaries. 

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

i looked through the code for the mandrake installer. exceptions are
being used for things that shouldn't be. a user clicking a button in the
app should not throw an exception on purpose, as in that's what the
button is designed to do. that makes for impossibly hard to
follow/read/maintain code. and just isn't good programming practice.

those apps could be written without the patches. there's nothing
inherent in perl-Glib/perl-Gtk2 that prevents it from being done.
similar things to what is being done in the exception handler could be
done in the callbacks for the buttons that throw exceptions.

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

send away. we've always looked at the things you all have sent, many of
them have been applied, when it was decided they were the right thing to
do.

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

if that distro had installed a hacked up version of libc4 then yes it is
their fault. by hacked up i don't mean bug and security fixes, i mean
adding facilities that aren't there in this version and won't be there
in the next. 

by no means am i trying to say that mandrake is the only distro that
does this sort of thing. in my original reply i mentioned redhat/pygtk
problems and that's just the one i have personal experience with. 

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

i have several projects at work, parts of which only use perl-Glib. for
several reasons. mainly objects with signals and properties are very
useful, and they are still useful in non-gui apps. it was one of the
reasons glib is completely separate from gtk+. saying there's no use for
glib/perl-Glib alone, is just wrong.

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

we don't ignore them, an error message is displayed and the app
continues. that leaves the burden where it always was, on the programmer
to handle the errors appropriately. an error message vs. dying is
another argument that i'll let muppet make if he so chooses, i don't
really care one way or another b/c when i write apps i handle the error
conditions appropriately.

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

they're not one shot, they can stay installed.

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

no doubt. and users are open to more problems like this.

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

i'm just saying that distro's should take steps to prevent it when/where
possible.

-rm