This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: On Cygwin package naming and a setup.exe bug


Bernard Dautrevaux wrote:

> Yeah, I agree, but in all places I know everyone, especially someone without
> a police record, is presumed innocent...


<gratuitous political inflammatory remark>
except here in the USA, w.r.t. the IRS.  Or the drug "war".  Or when 
carrying large sums of cash.  Or when driving-while-black.
</gratuitus political inflammatory remark>
   -- but please don't respond on-list; email me if you want.


> What I've read in the original posting was a discussion of how setup could
> be enhaced to allow installation of unofficial cygwin packages, TOGETHER
> WITH A PATCH and almost a firm commitment to rework it if it proves
> unacceptable.


There were two patches.  One was appropriate and was accepted.  The 
other was held in abeyance pending further discussion.  (Also, given 
that MASSIVE changes have recently happened to setup, yet VERY FEW 
people have tested them, the developers are a bit leary --at this 
point-- to adding yet more stuff, until the current <untested> stuff 
sees wider use.  (New setup should be available RSN))


> I've heard so much answer in the line of "Please provide a patch" for
> proposal of enhancements to setup.exe (and I perfectly understand that) that
> I was a bit bitten by the answer done to a proposal that was carefully
> explained and supplemented by a patch, which was in the line of "We have not
> expected you to use setup.exe for anything else than for what we design it,
> so your proposal was not interesting".


Well, you have to expect some bitterness.  Count the number of problem 
reports generated by people who don't even use OUR setup to install 
cygwin itself.  Geez.

Also, the MAIN motivation for the unaccepted patch was "I don't like the 
  your naming scheme."  (e.g. I want to name my package 
"foo-<ver>-<rev>-cygwin.tar.gz" not "foo-<ver>-<rev>.tar.gz" because the 
latter is too similar to our existing source tarball name 
"foo-<ver>.tar.gz". <umm, how about foo-cygwin-<ver>-<rev>.tar.gz?  No 
setup changes required!>  Also, since our source tarball is named 
foo-<ver>.tar.gz, I don't want to provide a duplicate named 
foo-<ver>-src.tar.gz -- <umm, ever heard of symlinks?>)

Name parsing, as simple as the concept is, is quite difficult to get 
right.  We have a proposal to gratuitously muck with name parsing -- for 
an insufficiently-supported reason, for which there are obvious 
alternatives that don't require mucking with setup.

(Plus, the discussion degenerated into a fight over GPL compliance; very 
little of this thread actually deals directly with the aforementioned patch)


> Please let me be clear: I understand all of you when you answer "requests
> for enhancement" by a "why don't you do it yourself: setup is open source".
> But rebuffing someone that *offers* to do the job, and even propose a first
> possible patch, by just saying "setup was not expected to be used that way"
> is a bit brutal.


Perhaps, but part of "maintaining" is being discriminating about what 
patches are allowed in.  Perhaps "we" can be a bit more politic -- 
"setup is going through changes right now, please ask again after things 
have settled" or "Your case for this proposal is not convincing.  Please 
take this to cygwin-developers and we'll discuss it"

OTOH, it takes a thick skin to work on a public mailing list; if you 
can't take the heat....  Anyway, the cygwin list is remarkably free of 
flames given the disparity in experience levels shown by the 
subscribers.  For some entertainment, read linux-kernel sometime...

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]