Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Message-ID: <3CBEE9DA.7050005@ece.gatech.edu>
Date: Thu, 18 Apr 2002 11:44:26 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Corinna Vinschen <cygwin-apps AT cygwin DOT com>
Subject: Re: strange source packaging?
References: <20020417210033 DOT GB20207 AT redhat DOT com> <49269 DOT 66 DOT 32 DOT 89 DOT 136 DOT 1019089317 DOT squirrel AT secure2 DOT ece DOT gatech DOT edu> <20020418110943 DOT D24938 AT cygbert DOT vinschen DOT de> <3CBEDBBA DOT 5040000 AT ece DOT gatech DOT edu> <20020418170631 DOT G29277 AT cygbert DOT vinschen DOT de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Corinna Vinschen wrote:

> I'm talking about style 2.  I'm using it for my packages.  I don't
> see a need that the Cygwin package needs the patch from the original
> version.  The pristine source is available elsewhere.  We're
> responsible for the Cygwin version.  In the long run the maintainer
> of a package should try to get his/her changes back into the main
> trunk anyway (I know, I never did that for inetutils).  So the
> whole point is to get rid of the extra Cygwin patch and to offer
> the pristine sources anyway since they already contain the Cygwin
> patches.  E.g the openssh sources are the original sources, just
> repacked to untar into the correct source dir according to our
> "standards".


I don't buy that "everything should go into the main trunk".  Do you 
really thing that the cygwin-specific readmes should be (or would be) 
incorporated into the upstream versions of all these project?  or the 
postinstall.sh scripts?

Even after all the substantive, code-based changes are accepted by the 
upstream folks, there are still a number of changes in the average 
cygwin package that just don't belong in the main trunk.

Now, if you're arguing that those non-trunk-worthy changes should just 
be shipped -- without a "reversal" patch -- then fine, let's have that 
discussion.  (For my part, it's academic; I prefer the rpm-like "ship 
orig source tarball + patch + script (spec file...)" style, anyway.)

The argument for style 1 against style 2 is this:  Does anybody, other 
than Chris, have ANY idea what the differences between gnu-gcc-2.95.3 
and cygwin-gcc-2.95.3-5 are?  How many files are changed, and how 
significantly?  What options were used to build the cygwin binary 
package?  Before Chris reluctantly picked up the duty, did anyone other 
than Mumit have a clue about the minutia of those differences (worse 
yet, Mumit's version was a fork of the cgywin version, which itself was 
a fork of the egcs version, which was a fork of the official gnu version...)

Granted, gcc is pretty much the 'worst possible case' example, but the 
end result was that after Mumit dropped out of sight, it was over a year 
before we had another gcc update.  (It was 18 months before some of the 
dll-building capabilities in binutils that Mumit had working in HIS 
version, were finally recreated/restored and pushed upstream into the 
main binutils trunk).

Forcing maintainers to generate and include an actual diff in each -src 
tarball for each new release serves as a kind of reminder: here's how 
much stuff still needs to be pushed upstream.

Heck, I evaluate my success with each release based on how much smaller 
that diff is...see ncftp...

Sure, this kind of thing is the maintainer's purview; perhaps it's too 
authoritarian to micromanage and say "you must do it this way" -- OTOH, 
the size of these patches also serve to advertise to the community how 
well cygwin support is getting mainstreamed.

BUT...having said all of that, I reiterate: I prefer the style 3 over 
EITHER style 1 or style 2 -- and the question here seems to be "document 
styles 1,2,3, or document 1,(!2),3 or (!1),2,3  So I win, regardless.  I 
really don't have a horse in the 1,2 vs. 1,(!2) vs. (!1),2 race.  So, 
I've made my argument for 1,(!2) but won't defend it; I'll wait for a 
consensus to emerge and will document the result.

--Chuck
P.S.  geez, I really didn't mean to restart that old November thread...