Re: [MinGW-dvlpr] mingw src packaging [Was: Re: mingw-get feature request]

[Earnie <ea...@us...>]

Charles Wilson wrote:
> On 8/26/2011 4:16 PM, Keith Marshall wrote:
>> With respect, I'm getting bored with this rant.
> 
> Me too.
> 
>> What's wrong with that?  You've got everything you need to distribute,
>> and no need for your "patches to update patches" difficulty.
> 
> Because it requires the end "user" -- actually, a dev who wants to
> rebuild from one of our -src packages -- to create a local CMS repo in
> order to repeat my build action.  With CVS (or svn), that's definitely
> overkill, since CVS can't init a repo in place -- and frankly, 'cvs
> init' is basically 'cp -dpr' with some additional overhead.  For "in
> place" CMS, like git (hg?) that's a reasonable idea -- except that we
> don't currently include either in our base package set (or at all,
> actually).
> 

Well, hardly.  A casual user of the source only wants to configure, make
and make install.  Some developer taking over maintenance of a package
or even one just interested in improving a MinGW package will setup a
repository of his liking from the upstream repo and reproduce the patch
from our provided source so that he can try to keep up with the upstream
patching.  The ratio of casual user to developer user is slanted to the
casual user by a wide margin.  So my preference for the source to
already contain the patch is due to the slant toward the casual user.
But your source packages do contain a script that can be used to
automate the process for the casual user; but your script causes the
casual user to never learn the simple basics of configure and make.
Both of our methods satisfy the GPL and the GNU package standards but
affect the end user differently.

I don't disagree 100% with your rantings of my style, I don't agree 100%
either.  My methods served the MinGW community just as your methods do
now.  We are all different and have differing styles of producing work.
 The one thing some are able to cope with more than others is adapting
style with changing methods especially when it is troublesome to the
soul.  Keith's method, your method, my method or someone else's method,
in the end the method that wins becomes what is good for mingw-get and
that will tend to be the one that is coding mingw-get; but I know Keith
is open minded to reason if someone's reason can be shown to be of more
benefit to the casual user.  It is the casual user that any method must
benefit since a developer will choose his own methods.

Earnie