This is the mail archive of the
mailing list for the Cygwin project.
Re: (new) pcre package for consideration
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- To: Ronald Landheer-Cieslak <ronald at landheer dot com>
- Cc: cygwin-apps at cygwin dot com
- Date: Tue, 06 May 2003 19:51:19 -0400
- Subject: Re: (new) pcre package for consideration
- References: <Pine.LNX.email@example.com>
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
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
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
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..
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]
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>