Re: [Fink-devel] libgnomeprint2.2-2.12.1-1001

[Michèle Garoche]

Le 24 févr. 2006 à 11:18, Daniel Macks a écrit :

. It seems
unlikely that an upstream package would have gone through a whole
unstable branch series then a new stable series and have serious

compatible", it's been tested by them (these versions are already
several months old), and we don't find any problems in some basic
testing and usage, that sounds to me like it's ready to release.

upgrade breakage or interface incompatibilities. So if they say "it's

See for example: <http://bugzilla.gnome.org/show_bug.cgi?id=326071>

Oh come on now...it doesn't make sense to say "we won't release until
every upstream bug including ones that aren't found yet are resolved".
Should we hold fink at 2.10.x until upstream 2.14 comes out (i.e., no
more bugfix release on the 2.12.x series) before fink goes to 2.12?
You also seem to be assuming that libfoo-2.12.0 doesn't include fixes
for bugs in libfoo-2.10.x. Also note that the bugzilla you cite is for
an odd version (standardly a development branch)...fink tends to stay
with stable/release branches specifically to allow upstream to shake
out the more blatant bugs like that one (which would have blocked
building of that package on *any* fink machine).

Sorry, I did not mean this. Simply that I tend to report bug at odd version, because it is a good way to have them fixed at even version, but this bug was already seen for a while and propagated in newer versions.

Fink has tried to coordinate

not very hard though.

I've spent the past five minutes trying to think of a polite way to
respond to that. I can't, so I won't.

Very sorry, I did not want to offense you. I apologize deeply.

a full gnome2.x suite in exp/ and fully
test all its interactions before releasing it.

The issue here is just a missing BuildDepends.

But how can it be?:-)

Because I don't test everything under every condition. Nor do you, nor
does anybody. We rely on others with different configurations to find
incorrect assumptions. If we only committed what worked perfectly
(even "perfectly within the limits of upstream") in all cases and
played nicely with all other packages, we wouldn't have an unstable
tree. Even for something as fundamental as dependencies, you're asking
that we not release a new version until we test-build it in the
presence and absence of every other package, and test every one of
those others in the presence and absence of the new one. The really
best we can do is try to get it right, and fix it when it isn't.

I agree completely here.

Stuff like that happens
all the time, and gets fixed as soon as someone on a system without
[whatever package] recognizes it problem. Or when someone discovers
some sepcific combination os packages that triggers some weird
interaction, for example, recent issues of libgnome2 + gnome-libs.

That's the problem here. As long as gnome would not be considered in
fink as some monolithic system like kde, it's likely not to work
properly.

Right. Because it's not monolithic and it's not even a well-
coordinated aggregate except on the first day of its release. It's got
a jillion packages that all have their own bugfix release schedules,
and mistakes that get made and then fixed, just like fink itself.

I mean just in the sense that gnome makes assumption that if some package is at xx version, some other is at yy version (like for example glib2.6 and gnome 2.8). The problem is what is gnome 2.8, and only gnome upstream team decides it at the first day of its release, as you pointed it out.

Cheers,
Michèle
<http://micmacfr.homeunix.org>

36C471DED4B09EEB30A0281F2608DB2FE6F9E147.gpgkey
Description: Binary data