This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: strange source packaging?
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...