(new) pcre package for consideration

Charles Wilson cwilson@ece.gatech.edu
Tue May 6 23:53:00 GMT 2003

Ronald Landheer-Cieslak wrote:

> I think this is slighty over-complicated, but only slightly.
> A bzipped tarball with cygpcre.dll, cygpcre-0.dll, cygpcreposix.dll and 
> cygpcreposix-0.dll is only 7 K larger than a bzipped tarball with only the 
> unversioned DLLs.

And when the API changes, you'll then pack cygpcre, cygpcre-0, and 
cygpcre-1 in the same package?  Then -2, -3 and -4?

This is not an extensible solution; your binary package grows without 
bound.  Unless you start eliminating DLLs from your binary package 
because in your opinion "enough time has passed" -- that is an evil of 
another sort.

Look, fine granularity is GOOD.  If none of my apps use cygpcre.dll, 
cygpcre-0.dll, or cygpcre-1.dll, but all use cygpcre-2.dll then I should 
only download and install the one I need.  libpcre2.

Further, how are you going to insure that the GPL is obeyed for the 
*old* DLLs?  You're shipping binary DLLs based on an older -src release, 
but there's no guarantee that both the old and the new -src packages 
will be there.  And, it'll become a maintainability hassle: okay, 
libpcre contains DLLs from pcre-4.0-2-src.tar.bz2 and 
pcre-4.2-1-src.tar.bz2.  But there's only one "source:" tag allowed in 
the setup.hint file for libpcre.

It's a mess.  Don't go there.

> IOW, two seconds worth of downloading on a 4K/s modem. 
> Putting both in a single tarball will make the libpcre0 package 
> unnecessary. The binaries (pcretest, pcregrep) will be linked with the 
> versioned versions, the devel files (good idea, IMHO) will link with the 
> versioned versions as well, and the unversioned versions will disappear 
> (with lots of flashing light in the announcement message, of course) after 
> a couple of weeks.

No, you are missing the point.  You may NEVER remove the old DLLs. 
Unless you know FOR CERTAIN that NO ONE in the entire world has built a 
private application that links against cygpcre.dll.

And even if you don't care about private apps, it's frelling rude to 
FORCE maintainers of official packages to rebuild their packages which 
currently depend on cygpcre.dll on your schedule -- just because you 
plan to remove it from your 'libpcre' package without providing a 
'backup plan'.

Look, the rule is: DON'T BREAK STUFF.

Your plan will break stuff.  Therefore, it is a bad plan.

Do you think I made up this procedure because I like working that hard? 
  No, it's been the product of > two years of maintaining the first set 
of DLLized libraries for cygwin as part of the non-monolithic 
setup.exe-based installation paradigm.  I HAVE done it the way you 
suggest: ncurses4 --> ncurses5.  It didn't work out well.

In this case, trust me: short cuts never are.

> That will allow the various users of pcre to catch up without breaking 
> anything, and with the small size of pcre, we can keep the unversioned 
> versions around quite a while if we want to..

No, you just said you wanted to remove them 'a few weeks later'.  But 
you still don't address the problem of what happens when pcre-5.0 
changes the API, and you need to switch to cygpcre-1.dll.

On to happier subjects....

>>Again, because your new cygpcreposix-0.dll is fubared.
> That's what I thought.
> The thing is: because I was the onle one seeing the problem until now, I 
> was beginning to think it might be a cockpit error "chez moi"..

It's that pesky 'make install' relink thing again...  On cygwin, we 
could probably modify libtool to never relink.  But IMO this particular 
problem will also (does also) affect EVERY platform: including those on 
which -rpath matters.  I'm surprised none of those platforms have 
stumbled onto this yet.

When I get the testcase written, I'll try it on linux and see what happens.

> I was kinda hopinh to avoid the package jugling (how do you write that 
> anyway?) but I do agree it's a better idea to use Libtool if we can..
> [snipped anecdote]
>>Send an email to the cygwin-apps mailing list, 
>>like this one:
>>"ATTN: Apache, Perl, Python, and Exim maintainers"
> I'll do that.
> [snipped (buried) the dead horse]

No comments...

>>So, cygpcreposix-0.dll IS properly linked to cygpcre-0.dll.
> I found that too, but..
>>Next, I did the 'pcre-4.2-1.sh install' and looked in 
>><srcdir>/.inst/usr/bin.  And whaddaya know:

> I found that too :\
> At least I'm not hallucinating - ye never can tell: I'm Dutch ;)

Nope, it's not just you.
>>Sorry that I didn't have better news.
> Actually, you showed that I'm not insane, which is nice to know ;)
> I don't much like the hack, but if it's the only thing to do to work 
> around this libtool bug, and if libtool 1.5.1 will not contain this bug, 
> I'll just put it in a chunck in the patch I can later remove..

Well, the fix will be in 1.5.1 if somebody writes the fix.  First step 
is to generate a smaller testcase than the entire pcre dist. :-)

One thing at a time...

> Thanks, Chuck, for your help.
> I'll make a new version of pcre available asap (tomorow, probably).
> Personally, because pcre is so very small, I think it's not really worth 
> it to break it up into three (or more) packages: a single pcre package 
> with two versions of the DLLs will increase download time by two seconds 
> for people using modems (does anyone use less that a 4K/s modem nowadays?) 
> Asking the cygwin@ list about it would create more trafic than two 
> separate packages will spare, and it's even more transparent to the end 
> user not splitting it up..


1) extensible after future API breakage

2) current cygwin standard packaging for DLLs and versioning is to 
split.  Period.  We tried not splitting and packing the old DLLs in with 
the new DLLs -- it led to maintainability hassles (especially after the 
second API change).

3) Worse, binary packages that contain compiled object code from 
multiple source releases are very difficult to insure GPL compliance.

> So, if nobody protests loudly, there'll be a single pcre package with two 
> versions of each DLL in it for a while (either until the next release of 
> pcre, or until the next full moon, whichever comes first ;)

Protesting Loudly!  <sorry>


More information about the Cygwin-apps mailing list