Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com From: Michael Ring To: cygwin-developers AT sourceware DOT cygnus DOT com Cc: m DOT ring AT ndh DOT net Subject: rpm-based installation of cygwin-485-snapshot Date: Fri, 24 Mar 2000 13:52:07 +0100 Message-ID: X-Mailer: Forte Agent 1.6/32.525 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id HAA03579 Hi! I would like to propose an alternative (or additional) installation method for upcomming cygwin-releases. I have compiled a rpm-based distribution equivalent to the cygwin-485 snapshot as a 'case-study'. My ISP does not give me enough filespace for all the files so I would like to update the dist somewhere to sourceware.cygwin.com (I will only upload if someone from cygwin confirms that i should/can do it) By using rpm (Redhat Package Manager) we will gain a lot of simplification in the build/install process for cygwin-executeables. Here some examples: installing/upgrading is super-easy, removal of old version is also easy and includes dependency-checking (You cannot remove a package if parts of it are needed by other applications) and you also get a brief description what an application does before installing it. Because every rpm is versioned it is easy to automatically update from a ftp/http server (That was one of the installer goals I read in this list) build-scripts are included in the src-rpm files. You can rebuild software from scratch and add patches in a consistent way building & installation can be automated, at work I am managing a distribution of Open-Source software for Solaris and OSF1 based on the same source-code-rpm's completely automaticaly (complete rebuilds take about 24 hours). rpm hast post-install and pre-remove scripts. In a first step we could use it to make the cygwin distribution a little bit more fhs 2.0 compliant by moving arround some files from /bin to /usr/bin without the need for the cygwin developers to change their build-methods I would like to discuss this approach with you guys, feedback is welcome! Michael Ring