Mail Archives: cygwin/2007/01/05/21:03:25
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/
- Raw text -