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: sqlite / pysqlite ... RFC/ITP?


Jan Schormann wrote:
Hi all,

I'm not sure just *how* off-topic this is, let's see ...

I'm using Reini's own package of sqlite 3.0.7 for cygwin
in conjunction with the pysqlite source-distribution.
This works quite well, only I'd like it all in cygwin
packages in the standard distribution.

For the record:

SQLite is a small C library that implements a self-contained,
embeddable, zero-configuration SQL database engine.
 -> http://www.sqlite.org/

pysqlite is a Python DB-API 2.0 interface for the SQLite
embedded relational database engine.
 -> http://www.pysqlite.org/


Now on to the real issues:


I might volunteer as maintainer for the pysqlite cygwin
package, but there are a few questions:

- Is anyone else actually interested in this, or might I be
  better off to keep it to my own?

Not known.


- Reini, will the sqlite package ever be part of the standard
  cygwin mirrors, or would I have to maintain that, too?
  Is there any serious reason against uploading it?

Would be nice to have you maintaining sqlite too.


See the cygwin-apps archive, there were some comms about sqlite, but
the provided package contains errors, I couldn't rebuild and so it was not uploaded. No fixes were provided so far (it is way long ago).



- The python setup script, shipped with the pysqlite source,
  builds and installs different DLLs, not only for different
  versions of python (e.g. 2.3 vs. 2.4 which isn't a problem
  as only 2.4 is supported in cygwin as of now), but also
  for each version of the cygwin dll itself.

There is only one python release at a time. Why are there different version needed for different cygwin versions? Older version of Cygwin are no onger available and are no longer supported, just build for the current version .

  This makes it look as if it's a bad idea to just package
  the "binary" ... But I have no real experience with that
  yet.
  Would I have to update it whenever a new cygwin version
  comes about, or is there a smart way around it - e.g.
  to call the actual build-and-install from the postinstall
  script? Sounds scary.
  Might it be OK to distribute a "pysqlite binary cygwin
  package" and rebuild it only as soon as it stops working?

Should not be needed? Most packages are older than the current Cygwin library.

Note also that this would be my first ITP ever. If I get
positive responses here, I'll take the ITP to cygwin-apps,
of course.

Thanks for any hints,
	Jan.

Yes please provide sqlite, it is needed for many applications nowadays. Then it we'll see what the problem with pysqlite is about.


Gerrit -- =^..^=

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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