OpenPKG CVS Repository
http://cvs.openpkg.org/
____________________________________________________________________________
Server: cvs.openpkg.org Name: Thomas Lotterer
Root: /e/openpkg/cvs Email: [EMAIL PROTECTED]
Module: openpkg-re Date: 09-Feb-2004 09:49:24
Branch: HEAD Handle: 2004020908492400
Modified files:
openpkg-re todo.txt
Log:
log known issue: Debian v3.1 ndbm trouble (background, discussion,
solution)
Summary:
Revision Changes Path
1.176 +58 -0 openpkg-re/todo.txt
____________________________________________________________________________
patch -p0 <<'@@ .'
Index: openpkg-re/todo.txt
============================================================================
$ cvs diff -u -r1.175 -r1.176 todo.txt
--- openpkg-re/todo.txt 9 Feb 2004 08:47:20 -0000 1.175
+++ openpkg-re/todo.txt 9 Feb 2004 08:49:24 -0000 1.176
@@ -80,6 +80,64 @@
- cvstraq bug:
http://cvs.openpkg.org/timeline?x=1&c=2&dm=1&px=openpkg-src/apache shows
both apache and apache2 timeline
+ KNOWN ISSUES
+
+ o Debian v3.1 ndbm trouble
+
+ - fact:
+ the "sarge" release will not include a ndbm. We have applications
+ that still require the ndbm API. Our choices discussed were:
+
+ - include ndbm in OS:
+ not possible. We are not involved in Debian release engineering
+
+ - drop support for OS not offering ndbm:
+ not acceptable. According to our primary sponsor's lead engineer
+ UNIX, Debian is the #1 important Linux distro for them because it
+ allows machines to be setup once, run and being maintained for a
+ long time without having to reinstall the OS. Support for this
+ platform is mandatory.
+
+ - drop support for application requiring ndbm:
+ bad idea as apache 1.3 mod_auth_xxx is one them.
+
+ - port applications to not use ndbm:
+ not acceptable as a quick hack. Although a good long term goal we
+ are too deep into the release engineering process to accept that
+ additinal workload which has a completely unforseeable scope.
+
+ - provide ndbm for OS:
+ fixing/enhancing the OS itself is beyond the scope of OpenPKG.
+
+ - use OpenPKG gdbm with ndbm support
+ this is the easy way to go for fresh installs that use OpenPKG
+ applications only. That's why we picked it, see "ndbm" section in
+ upgrade.txt.
+
+ However, installations mixing vendor and OpenPKG stuff and
+ existing installations upgrading might run into trouble. The
+ reason is that gdbm::with_ndbm supports a ndbm API, makes the
+ build process of the application happy and allows them to install
+ and run. But the gdbm::with_ndbm file format on disk is very
+ likely different from that of the vendor's ndbm implementation.
+ Upgrades from OpenPKG v1.3 will have used the vendor ndbm
+ previously. Now they use gdbm::with_ndbm. Any damage can happen,
+ from destroyed ndbm files to appliation crashes to application
+ malfunction (i.e. apache mod_auth_xxx unable to read old ndbm
+ and accidentally grant access). Both fresh installs and upgrades
+ might run into trouble when they mix vendor and OpenPKG software,
+ i.e. use a vendor password creation/maintenance tool which writes
+ vendor ndbm files and use OpenPKG v2.0 application which reads
+ gdbm::with_ndbm file format.
+
+ Upgraders have two options:
+
+ 1.) build gdbm with_ndbm=no and build apache with_gdbm_ndbm=no.
+ This reverts to the old behaviour of using the vendor ndbm
+ and, of course, only works on OS that provide one.
+
+ 2.) convert/recreate your ndbm databases.
+
REJECTED SCOPE CREEP (but needs to be discussed post release)
o decide whether *-2.0.0.(src.)rpm should require: openpkg-2.0.0-2.0.0 or not
and why (not)
@@ .
______________________________________________________________________
The OpenPKG Project www.openpkg.org
CVS Repository Commit List [EMAIL PROTECTED]
