Re: cp error -- oh the great sanity of *nix tools?!?

["Charles S. Wilson" <cwilson at ece dot gatech dot edu>]

Soren Andersen wrote:


>> Sure.  For starters, gdbm is GPL, and GNU (FSF).  BerkeleyDB is NOT.
>> There are certain license restrictions -- which should not cause any
>> issues with cygwin, but let's be honest: there IS and always will be a
>> certain bias *against* non-GPL (free-speech) software in this forum.
> 
> 
> Sure, I am aware of that. I like to forego the most heated of the religious
> debates when the main point is to talk about getting things built. For me
> the point that BerkeleyDB has a license which *doesn't* pose problems with
> Cygwin is the most immediately significant one.

Let's put it this way.  I wanted to port CVS.  CVS can use either BerkDB 
or GDBM(ndbm-emulation-mode).  I preferred, for "religious" reasons, to 
use GDBM -- to the extent that I took heroic efforts to get 
CVS+gdbm(ndbm-emulation-mode) to work on FAT disks.  So I ported and 
support gdbm.  Not BerkDB.


>> The binary, precompiled package in contrib/perl/perl-5.6.1-1.tar.gz does
>> not include BerkDB support.  That's what most people are going to use;
>> hence: "the official Cygwin perl is built without db support).
> 
> I don't have the wide knowledge sufficient to have known what most people
> are going to use, and I wasn't sure you weren't using the `db' generically
> here -- now I think its confirmed for me that you were. 

No, I mean BerkDB support was not included in the official Cygwin perl 
binary.  GDBM db support IS included in the official Cygwin perl binary.

> But this leaves me a
> little confused, further, to wit: isn't gdbm commonly downloaded/installed
> by Cygwin users, and so would be available (just FYI I didn't -- as one
> would certainly hope! -- have to do anything special to get Perl to find
> libgdbm)? Or is gdbm just very newly added to the standard Cygwin distro
> packages? Anyway ..
> 
> 
>> However, if YOU have the BerkDB library on YOUR system, and download
>> contrib/perl/perl-5.6.1-1-src.tar.gz and BUILD it yourself on your
>> system, YOUR version WILL have BerkDB support.
>> {...} Yes, the *source code* of perl, as ported to cygwin, does support
>> BerkDB if you have it.  Thus, the README talks about BerkDB support

>> However, the particular binary that is installed by setup doesn't include
>> that capability.
>
> I understood this :-).
> 
>> One other thing -- Michael's db3 port was dll-ized.  My db2 port (and
>> yours, I suspect) are static lib only.
> 
> Yes, I built a static lib.
> 

<SNIP stuff about NTFS/FAT build differences>

> 
> [Soren, regarding finding BerkDB on Charles' site]
> 
>> I dunno.  I really don't have much time to tweak that site anymore, now
>> that I (and others) have repackaged almost everything of interest from
>> CygUtils so that they're now installed by setup.exe and are part of the
>> "official" distro.
> 
> It has been a great help, anyway.
> 

<SNIP>

>> Interpretation:
>> "The official perl doesn't have the extensions I want.  Some of these
>> desired extensions depend on external libraries that aren't official.
>> Therefore, the official perl won't get my desired extensions until the
>> external library is "officialized" -- and then the perl maintainer will
>> need to rebuild perl to use the newly official library, so that my
>> desired perl extension is built and included in a new perl package.  But
>> he might not ever do that and then I'll never get my desired extension
>> even if I manage to get the necessary libraries officialized. That makes
>> me sad." <g>
> 
> 
> Well, that's a pretty good summing-up.
> 
> 
>> Response:
> 
>  {... a lot, then: }
> 
>> So, to sum up: if you want the "missing" blessed extensions to be
>> included in the official cygiwn-perl, then help make the required
>> libraries (and functionality) a part of cygwin.  Port & support BerkDB.
> 
> 
> Hmm. Interesting. What I meant about "authors not being allowed to finish
> writing their software" was that the version of BerkDB that many people are
> using with DB_File is, AFAIK, N.xy, where N is probably 2 (because the 1.xx
> code is *really* old by now) and x is probably 7 and y might (as well) be 7;
> and AFAIK this goes for the wider Perl community, _not just
> Cygwin_ -Perlers; so why does Cygwin have to have stricter standards than
> are common in the Perl user community? I mean, if Eric has already done this
> work on BerkDB3 I can see the reluctance that might exist to 'waste' that
> effort, but *that aside*, theoretically, why cannot the "standard BerkDB"
> that is used with Cygwin and Cygwin-Perl be 2.77? 

You're not listening.  There is NO "standard BerkDB" for cygwin because 
NOBODY has packaged ANY version for official inclusion in the 
distribution and promised to be its maintainer.  I (sortof) ported 2.7.7 
at one point on my cygutils website -- but I never took the extra step 
of dll-izing according to the "new" scheme or packaging it up for 
official inclusion.  I am not willing to take on, port, or maintain 
another package.  I'm swamped.

Also, since many many changes have occurred in cygwin since I did that 
ancient port, I'm no longer sure my "port" even compiles anymore.  And, 
it certainly doesn't do DLL-building "correctly" (where "correct" == 
current method as used in readline, jbig, tiff, jpeg, zlib, png...)

As I said earlier, ANYONE is free to take my port of 2.7.7 and update it 
to follow the new setup.exe-based packaging standard, and update the 
DLL-building stuff to "conform" -- and ask that this NEW port of 2.7.7 
be included in the distro. (Except that we're currently in a 
no-new-packages freeze until the changes in setup.exe settle down)

However, let me caution against that: Sleepycat no longer supports or 
recommends the 2.XY series of BerkDB software.  Therefore, if one is to 
go thru the effort of porting and testing and maintaining and packaging 
a new "BerkDB" package, doesn't it make sense to do all that to the 
current code base?  e.g. 3.XY ?

About a year ago, Michael Ring and I bounced several versions of 
db-3.1.17 back and forth.  He promised to finish it up and propose it 
for inclusion in the official distro, but he seems to have dropped off 
the list a while back. (Michael, are you there?)  I still have the most 
recent version we cobbled together; this version "db-3.1.17-2" obeys the 
cygwin packaging standard and naming conventions, there's a -DDB_STATIC 
flag for static linking, etc.  (Although Sleepycat released 3.2.29, the 
very next public release after 3.1.17, on Jan 24, 2001...sigh)

Also, the last message I got from Michael on the subject cautioned about 
conflicts between db1 and db3, and mentioned that he had come up with a 
workaround in which he created implibs for both versions (from the same 
3.x.y sourcecode?)  So, I'm not at all confident that the "3.1.17-2" 
package that I have is "good".  Anyway, I never did see Michael's post-2 
updates.

Michael, you wanna chime in here?

> Is it because BerkDB3
> offers so much more in the way of progress, improvement, *and because*
> Cygwin developers are going to want it for more than just the 'blessed' Perl
> module DB_File? (you see, I am such a monomanaical Perler that this hadn't
> occured to me until now). 

There is no "BerkDB" policy.  Nobody has stepped forward to support ANY 
version of BerkDB, so it hasn't been an issue.

> And .. if that *weren't* the case -- if making
> 2.77 the "official" lib for Cygwin was countenanced -- what degree of
> "support" would we be talking about? It's a very stable thing that's been
> around a long-ish time; I think of it as just 'doing what it does' without
> much fuss. And is DB_File going to change? AFAIK its also been very stable
> for a long, long time. The module and the lib sort of go together closely in
> a case like this, I thought, and are both very stable (if not stagnant ..),
> so isn't this "finished"? If there are "bugs" (not special "Cygwin-specific
> bugs") in this (and I suppose there _always_ are ..) aren't they just going
> to stay there? This is what I meant by "being allowed to finish writing
> [some software]."

Some of the changes can be unrelated to the base package's code.  For 
instance, what if libtool suddenly supports building dll's "cleanly" -- 
but requires all dll-ized packages to be rebuilt with certain changes? 
Or worse, about 18 months ago the decision was reached that dll's on 
cygwin should be named "cyg<pkg><VER>.dll" -- requiring me to recompile 
ALL of my dll-ized packages to follow that naming scheme.  Fortunately, 
that kind of disaster doesn't happen often.

Sure, db-2.7.7 may not change, but external events can force a 
maintainer to rebuild the package on occaision.  (See my recent slew of 
updates to dll-ized packages, so that -DALL_STATIC can be used as an 
alias for -D<pkgname>_STATIC when linking client apps statically)


> See, I am too ignorant of what some of the terms you are using mean to you
> and other Cygwin folk and those in parallel positions to yours. I do know
> that: I don't think I am qualified, frankly, to offer user-level support on
> a database lib, so what Cygwin apparently wants as a package (not just a
> one-off "Makefile Makeover" <g> but that AND a developer to go with it ...)
> it cannot get from me. If I *could* do it, I would, but it isn't just a
> matter of personal available time (which is also very scant for me), it is a
> matter of capability/qualifications. I would need a LOT of hand-holding by
> somebody at Cygwin, at the least.

Well, you never learn by sitting on the sidelines.  I only learned by 
diving in (without checking the water's depth, as it turned out...<g>)

 
>> The "regular" extensions can be built using the CPAN shell.
> 
> 
> Yes, the regular extensions are no problem, CPAN is no problem (Uhh, well,
> basically, uhhh, actually, it hasn't been able to build a lot of extensions
> for me just recently and I don't know why -- parse errors in the
> Makefile.PLs that don't show up, when I resort to building manually ...
> arrgh).

This is a common complaint.  I think there may actually be a 
(non-newbie-related) bug in there somewhere.  Perhaps when Eric returns 
he can take a look...

> 
>   Anyway, I wanted to get back to you and the List with some comments and
> clarifications since I sounded off fairly loudly for a moment there. I feel
> that I have learned a lot from your substantial reply, and so thank you
> again, Charles. I appreciate the time you took to write it.

No prob.

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/