X-Spam-Check-By: sourceware.org
Message-ID: <459F034C.7040609@cwilson.fastmail.fm>
Date: Fri, 05 Jan 2007 21:02:52 -0500
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Updated (and new) cygport patches
References: <456BEA91 DOT 9020100 AT cwilson DOT fastmail DOT fm> <456BF15E DOT 3090501 AT cwilson DOT fastmail DOT fm> <457A5FA0 DOT 9090601 AT cwilson DOT fastmail DOT fm> <45862810 DOT 40009 AT fastmail DOT fm> <458B8C37 DOT 8050402 AT users DOT sourceforge DOT net>
In-Reply-To: <458B8C37.8050402@users.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Yaakov S (Cygwin Ports) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Charles Wilson wrote:
>> Yaakov: Of the 7 patches I've posted recently, I expect that only two
>> will require in-depth analysis before you apply them.  The rest are
>> pretty straightforward:
> 
> Thanks for being so on top of these, because I was beginning to lose
> track among all the noise (on this list and in my house :-) ).
> 
> BTW, would it be easier for cygport developers if I open a bug tracker
> on SF.net?  (/me wishes for bugzilla, but...)

I wouldn't worry about that.  Most patches are much smaller and easier 
to review than my behemoths.  Look how quickly Eric's recent small patch 
was reviewed and added to CVS...even in the midst of your recent 
excitement.

>> [1] cygport-ac2.61.patch and
> 
> 2.61 is now supported in CVS.

Not entirely -- you missed a spot in cygconf().  I'll post a patch in a 
separate thread; datarootdir should be used with both 2.60 and 2.61 (and 
later, but that's a worry for another day)

>> [1a] http://www.cygwin.com/ml/cygwin/2006-11/msg00720.html
>>        these two are holding up the release of autoconf2.5-2.61
> 
> I would like to test autoconf-2.61 first to understand this better.
> Does the attached tarball build with cygport CVS HEAD and autoconf-2.61
> installed?

Well, sorry this is a bit late, but the tarball attached to your message 
didn't exactly work: prep, build, install, pkg all worked -- but check 
did not.  Closer inspection showed that the tarball attached to your 
message was quite different from the 0.2.7 you actually released.

The actual, released cygport-0.2.7-1-src tarball worked fine for 
prep/build/install/pkg AND check.

> I'm considering this issue a BLOCKER for 0.2.7, and I want to roll it as
> soon as this is working.

As you had already concluded, 0.2.7 works with ac2.61.  The only missing 
bit is not a "breakage", but a "prefer" issue (with ac2.60 and above, 
use --datarootdir in preference to --datadir, --infodir, and --mandir).

>> [2] cygport-mixedmode.patch [*]

NOTE: the PATCH_URI functionality in 0.2.7 is not sufficient to 
reproduce all of the functionality of this patch.  Sometimes "upstream 
patches" are not distributed as .patch files.  They can be .zip files 
that contain new files to be copied into srcdir plus a script to run 
that itself modifies srcdir files (as in rxvt-unicode-X-7.7-5) or 
tarballs that include a patch as well as some binary test images (as in 
lossless jpeg).

PATCH_URI is good for the most common case -- vim, ncurses, readline, 
bash all provide one or more plain .patch files between major releases. 
  But you can't foresee the needs of all possible situations -- and if 
you did, cygport's code would be a nightmare.  PATCH_URI provides good, 
basic functionality -- but there are packages that need more 
flexibility/power...rather than anticipate or special-case all possible 
situations, cygport should provide basic tools that client .cygport 
files can use to satisfy the needs of that particular package.  More on 
that, below.

>> [3] cygport-multiple-postinstall.patch
>> [4] cygport-install-hooks.patch (this one)
> 
> I want to get 0.2.7 out first.

OK.  It's out.  I'll update my patches and post each in a separate 
thread.  Obviously, cygport-ac2.61 will be a lot smaller.

>> [*] also includes what could be termed "prep hooks" similar to the
>> install hooks provided by the attached patch, but which allow cygports
>> to intervene in the automated portion of src_prep.  I could split this
>> out into a separate patch if you prefer.

> Perhaps; I'm still hesitant about the hooks concept, as I'm afraid it
> may be abused.

I will move all "hooks" functionality into a separate standalone patch. 
  I do not understand your objection to them -- "abuse" is an odd term. 
cygport is a tool, and at present does not have sufficient power to do 
all the things required of it.  These patches add that power.

Of course, power can always be "abused". But by what definition?  Are 
you trying to enforce some policy via the cygport code?  What is that 
policy, and who decided what it should be -- did I miss the discussion? 
  Worse, enforcement of policy via opensource code is doomed to 
failure... <longwinded dissertation on open source, forks, the 
inadvisability of enforcing policy via code, and 
sofware-nanny/big-brotherism snipped>.

Besides, cygport is a tool for cygwin package maintainers.  If a 
maintainer "abuses" the tool's power -- who cares? (And who decides what 
constitutes "abuse"?)  This is *policy* -- and policy is best determined 
(and enforced) by human interaction, not by deliberately crippling 
cygport's code (crippleware is a proprietary software "technique" that 
has no business in opensource code -- because somebody will uncripple it 
in short order).

Now, if some maintainer did something truly evil (like hiding a trojan) 
-- well, it would be dealt with very quickly I'm sure, by us humans on 
the mailing lists, but that's outside the purview of cygport. "Abusing" 
cygport, as you alude to, is a much less serious offense -- if it is an 
offense at all!

>> [5] cygport-relocatable.patch
>> [6] cygport-custom-cmds.patch
> 
> And these as well, although I think the relocatable patch will be first,
> as its effects are isolated.

Wow, I figured the relocatable one would be LAST, because
   (1) it really is only needed by at most two packages at present, and 
only when those packages are built in a non-standard way
   (2) it's the MOST invasive of all: ${_RELOCDIR} sprinkled everywhere, 
modifications not just to cygport.in but also some lib/ files, etc.
   (3) number of lines changed/added is largest of all of my patches
Sure, when turned off it has zero effect, but that's not the usual 
definition of "isolated".

Look for a number of posts in the very near future, with updated 
versions of my various patches.

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/