next message in archive
no next message in thread
previous message in archive
previous message in thread
Index of Subjects
Index of Subjects On Thu, 14 Oct 1999, Jeff Warnica wrote: > I suspect the usul target system for cuite (today) is some kind of linux > install, and there are easy ways to upgrade not-quite-csuite packeges with > modern linux's, .rpm's and .deb's... CSuite isn't just for Linux. We run it on Solaris here, and a BSD port is (sort of) in the works. RPM and DEB aren't really all that much smarter or easier to use. './configure && make' is just as (non)-obvious to a novice as 'rpm -Uvh blah.rpm' > By putting everything under $cs_root you make it so admins have to have > special case abilities to maintain it.. I don't really agree with that. IMHO if an admin can't mentally replace all occurrences of "/usr" with "/opt/csuite" when reading docs, then they really shouldn't be upgrading a package on their own. > Have a csute.rpm with dependencies on apache.rpm etc... I have thought a little about porting rpm to be more platform-generic, and using that to determine package dependencies for installation on a particular machine that may already have a package installed, but I think it'd be easier and more effective to do it with shell scripts. We don't have simple RPM-style dependencies (csuite -> apache); we specifically need Apache with mod_rewrite, mod_foo and mod_bar compiled in or configured as options, and we need to edit httpd.conf to enable authentication in the right directories, etc. > In the last coule of months here, three different people have tried to > anwser the same question (total usership, IIRC) with three different methods > of sucking information from the db's. And the've gotton three different > anwsers. > This well could be a GIGO problem, but it does point to some king of > fundmental lacking in csute, a flakey db, or just a undocumented one. Mostly because they (we?) all used different approaches to get the same data, or defined "usership" in slightly different ways. The data is all there in the namedb; data quality degrades slightly in ud6 (a nightly-built single-file cache of namedb). Historical and economic data is all over the place. But we're working on it.
next message in archive
no next message in thread
previous message in archive
previous message in thread
Index of Subjects