On Mon, May 03, 2010 at 05:11:32PM +0200, Max Horn wrote:
> Jack,
>
> this is ridiculous. First off, nobody holds you hostage to anything. And that
> you call JF's well thought and politely formulated questions, suggestions and
> objections "whims" is simply inflammatory and insulting. Let's try to scaled
> down on the ad-hominem attacks, too, OK?
>
> Discussion and discourse of potential or perceived issues with a package are
> *normal* and a positive thing. It could indeed turn into a problem if it was
> true what you asserted earlier, namely that every developer out there would
> and could hold up changes based on a personal whim. However, this is simply
> not true and not the case: First of, in my experience nobody here acts out of
> a whim. They are all intelligent and capable people. Secondly, of course
> objections can turn out to be unfounded, or it can turn out that one wants to
> ignore an objection -- this can happen and is perfectly acceptable if there
> are good logical arguments that explain why the objection is invalid/not
> important/to be ignored. But just saying "Hey, I already put a lot of work
> into this, shut up!" is not a valid argument.
>
> Secondly, we do "eat our own dog food" when it comes to huge and complex
> packages as GCC. If this was my package, I *definitely* would not simply
> check that in, I would ask other team members to review it and give me
> feedback and help me iron out as many issue as possible with it *before* I
> subject tons of other developers to this.
>
> To get back to my initial point: you are not a hostage to anybody. If you are
> not interested in collaborating with others, but rather just want to push
> your personal agenda through, and are not willing to *listen* to constructive
> criticism, then you are free to spend your skills and spare time on other
> things.
>
> If, however, you really are interested in bringing a good (set of) gcc4x
> packages to Fink users (or MacPorts users, etc.), then scale down the flames,
> and think about suggestions people make to you, and discuss them seriously --
> and, if the suggestions turn out not to be useful / realistic, politely state
> why so, and then reply etc. -- and then, as it has happened in countless
> previous examples, this process will converge pretty soon and everybody will
> benefit.
Max,
This is the proposal....
---------------------------------------------
other pkgs : I gave you in my comment below the
example of gettext-bin _ a basic pkg, maintained
by fink-core ...
how to install: fink install gcc-4.X.Y
But the intent is clearly to accelerate
upgrading , in order for users an pkg submitters
not to stay stuck with museum-gcc's,
just because they forgot to check for the
presence of a new number, ending up in a
situation where about every pkg uses its
own version of gcc, for purely accidental
reasons.
The suggestion does have the slight disadvantage
that new pkgs, IF they want to depend on a
specific version of gcc (but no pkg takes such
precautions against upgrades of Apple's compilers),
have to Depend on gcc4X-compiler, and put
%p/lib/gcc4.X/bin first in PATH
But existing pkgs don't have to be modified
(provided the existing gcc4X pkgs are not refactored !),
assuming just that in your upcoming gcc-4.4.4 pkg
you add "gcc" itself to the Conflicts and Replaces.
This would still cause slight trouble with the pkgs still
depending on gcc42 or gcc43 , users having to manually
install that dep.. I'd think there are few such pkgs,
and that there are anyway probably reasons to upgrade
most of them.
But some seem to have reasons (dx, pdftk).
Probably it would be worth, for those 2 pkgs, to add also
to gcc42 and gcc43 a Conflicts/Replaces for "gcc"...
Hopefully very few users still need those old versions,
so few would have to re-compile ...
And the same thing would anyway have to be done
oterwise for the upcoming gcc-4.6 for those pkgs..
This is "biting the bullet" once; after this, no more trouble
ever of this sort.
Jean-Francois
-----------------------------------------------
As I read this, we will have to force users requiring
gcc42 or gcc43 to have to rebuild those with ones containing
the necessary Conflicts/Replaces for "gcc". So when someone
installs gcc45, they may well be forced to build and install
gcc42, gcc43, gcc44 and gcc45. Can you think of a better way
create flak for me from end-users than that?
Jack
>
> Bye,
> Max
------------------------------------------------------------------------------
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
