GNOME.org
 

Re: Build problem Gtk2-1.037

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.


as i already said, current perl-glib/gtk2 in mdk support both
mechanisms.

see below for why it's stupid to install newer bindings on mdk 9.1 and
9.2.
 

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.


you obviously have *not* look at how it's actually done in mdk10.
ugtk2 install an exception handler (not in your way) that exits the
main loop.

we actually implemented long time ago what muppet has just proposed,
but with a few changes in infrastucture.


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.


there's one *single* button that use exception: the cancal button,
enabling direct exit.

99.99% of our exceptions are used to handle lowlevel faillures (such
as those of mkfs, fsck, rpmdb and the like or those trigerred by file
removal, writing faillures, ...) or program bug (eg: writing "if
($bool print }" should just the program to exists instead of silently
ignoring the fact that's not perl code).


with your scheme, a program bug that would normaly make the perl
interpreter stop the program now discard the error by default.



actually i'd to complain loudly so that glib binding does not discard
previous errsv. it would be much saner to not ignore exceptions by
default and to exit program in case of ignored errors.


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.


but the fact that errors are silently discarded by default (yes i do
not think error messages on console account)


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.


actually, you didn't.
things were fixed b/c *I* cared about it and resent the actuall bits
to muppet.

just do not lie.


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.


you totally miss the point:

the point is that libc4 was binary incompatible with libc5 (and i do
not speak about the few api changes du to linux specific side in
libc[34])

the point is that perl-gtk2-xs was incompatible with perl-gtk2 (thus
installing the later on mdk9.1 is dumb).

the point is that perl-gtk2-xs >= 0.97 is incompatible with prior
releases (thus installing newer release on mdk9.2 is dumb).

we choose to stay backward compatible with perl-GTK.

mdk10.0 use current stable perl-gtk2 release

we patch lot of packages b/c of issues and we provide a set of
packages that work together.

you can update kernel on mdk9.1 to 2.6.0 and you can complain than
scripts and tools were not aware of kernel behavior changes due to
2.6.x, but that's a user bug, not a distro bug.
distro came as a working set with appropriate way of uprading.
blinding updates equals shoot in the foot.


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.


and mdk10.0 will both support your scripts *AND* our tools.
but you just hasn't checked...


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.


and this is totally incompatible of traditional way of dealing with
errors in perl.
unhandled exceptions should just exit the app with a trace message,
not silently continue.


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.


so, you intended to mean than mdk does not handle the error conditions
appropriately ?
 

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.


and how can we prevent the user to do anything? he can just replace
and break everything he want (kernel, glibc, x11, ...)

we patch stuff for good reasons.

a car manufacturer can add ABS device so that the car does not go out
of the road when there's snow on the road.
if the user "upgrade" his car by removing that system and adding
wheels from competition cars and had an accident, it's his own
problem, not manufacturer one!
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]