From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20151 invoked by alias); 31 Oct 2004 19:04:58 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 20109 invoked from network); 31 Oct 2004 19:04:58 -0000 Received: from unknown (HELO rwcrmhc12.comcast.net) (216.148.227.85) by sourceware.org with SMTP; 31 Oct 2004 19:04:58 -0000 Received: from [192.168.181.128] (unknown[67.176.41.158](misconfigured sender)) by comcast.net (rwcrmhc12) with ESMTP id <2004103119045601400sc3q5e>; Sun, 31 Oct 2004 19:04:57 +0000 Message-ID: <4185374F.8000101@phy.cmich.edu> Date: Sun, 31 Oct 2004 19:09:00 -0000 From: Eric McDonald User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) MIME-Version: 1.0 To: ejessen@adelphia.net CC: Skeezics Boondoggle , xconq7@sources.redhat.com Subject: Re: SDL Interface Development References: <20041031162812.SIHQ2188.mta11.adelphia.net@mail.adelphia.net> In-Reply-To: <20041031162812.SIHQ2188.mta11.adelphia.net@mail.adelphia.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01383.txt.bz2 Hi Erik, it's been a while since you've been heard from, > 1. it should be OS-independent All of it is. > 2. it should be included inside the Xconq build. Otherwise, you can spend forever just trying to get > everything to compile clean, before you can start any > work. Possibly. I think that between providing installers for precompiled binaries for MinGW32 and providing source RPM's for Linux and other platforms, there may not be a need to bundle everything together. But, if you, Skeezics, and others would prefer a giant source tarball with all the dep config scripts slaved to Xconq's one configure Script to rule them all, I will consider it. I would still prefer to provide the packages separately. Among other things, it will help to foster good will with the developers of the various prereq software components. > You've raised the barrier to entry so high, that > nobody but the most fanatical will attempt to maintain > the code. Which means the program will die out when > the fanatics move on. As I mentioned in earlier postings, it is not necessary to always keep up with the latest and greatest. It is enough to set a standard as far as the prereqs go, and then adhere to that standard. Upgrades to the prereq packages only need to be done occasionally. Eric