This is the mail archive of the cygwin 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]
Other format: [Raw text]

Re: Updated (and new) cygport patches

Yaakov S (Cygwin Ports) wrote:
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  (/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)

       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 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.


Unsubscribe info:
Problem reports:

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