Unbeknownst to me when I took the package over, the 1.12.x series
(represented now in both stable and unstable) are in what upstream
calls their "feature" branch. There have been some problems reported
with both 1.12.12 (our stable) and 1.12.13 (our unstable). 1.12.12
had problems in some locations when the time stamp had a "D" in the
middle of it (i.e. daylight savings time). 1.12.13 seems to freeze
up occasionally--this seems to correlate with large checkouts using a
compression factor of 3, e.g. a selfupdate-cvs.
As I see it, the options are:
1) Leave things the way they are--I'm not in favor of this.
2) Update our stable to 1.12.13 in spite of the lock up issue. One
reason in favor of this is reported in the NEWS file for 1.12.13:
* CVS now uses version 1.2.3 of the ZLib compression libraries in
order to
avoid two recently announced security vulnerabilities in them.
Both may be
used for denial of service attacks and one may reportedly allow
execution of
arbitrary code, though this is not confirmed. Please see the CERT
vulnerabilities advisories #238678 <http://www.kb.cert.org/vuls/id/
238678> &
#680620 <http://www.kb.cert.org/vuls/id/680620> for more.
I had hesitated to do so because I had hoped to resolve the
compression-lockup issue, but I failed to find a solution.
(NOTE: 10.4.4 appears to have zlib-1.2.3 as well)
3) Add .info files for the latest upstream "stable" version--1.11.21
(a 1.11.20-1.info is already in both 10.3 and 10.4 unstable, which I
had forgotten), along with language in DescDetail suggesting that
users downgrade if they experience problems.
4) Make a 1.11.21 "cvs-stable" package. This would Provide: cvs,
Conflict cvs:, and Replace: cvs. The existing cvs package(s) would
be modified to Conflict: and Replace: cvs-stable. This is a
relatively simple option which allows, but doesn't force, downgrading.
This version, however, does come with an old zlib (1.1.4) We can
have it use the system's version, though this is really only
advantageous on 10.4, since 10.3 still has 1.1.4.
I'm currently in favor of 2) in spite of the lockup issue.
I kind of like having the older version around so that people can
downgrade temporarily if anything in the 1.12.x tree becomes nasty.
2) + 3) would be easy to implement.
2) + 4) isn't too bad, and has the virtue that if people want to
stick with the 1.11.21 version it won't get automatically overwritten.
Thoughts?
AKH
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel
