This is the mail archive of the cygwin-apps@cygwin.com 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: (new) pcre package for consideration


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"
http://www.cygwin.com/ml/cygwin-apps/2003-03/msg00675.html

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

Except:


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>


--Chuck



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