Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <421E7FF4.5242D232@dessent.net>
Date: Thu, 24 Feb 2005 17:31:32 -0800
From: Brian Dessent <brian AT dessent DOT net>
Organization: My own little world...
MIME-Version: 1.0
To: "'Cygwin List'" <cygwin AT cygwin DOT com>
Subject: Re: packg mngmnt model & other cygwin package releases...(where did they come from?)
References: <42091B63 DOT 1080908 AT tlinx DOT org> <20050208234325 DOT GA2944 AT efn DOT org> <420AAF5E DOT 1030506 AT tlinx DOT org> <420AB5EC DOT 1070904 AT familiehaase DOT de> <420BB627 DOT 7040905 AT tlinx DOT org> <20050210200410 DOT GA3728 AT efn DOT org> <420BEEB6 DOT 3070303 AT x-ray DOT at> <421CCF9A DOT 5010202 AT tlinx DOT org> <Pine DOT GSO DOT 4 DOT 61 DOT 0502231348470 DOT 25676 AT slinky DOT cs DOT nyu DOT edu> <421CEAE3 DOT 3080401 AT tlinx DOT org> <20050224104137 DOT GE5708 AT efn DOT org> <421E4F05 DOT 5020404 AT tlinx DOT org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com

Linda W wrote:

> But all of this discussion is moot if there is no high level
> interest in providing 3rd party links or a cygwin-contrib
> section to setup.  Having all package dependancies specified
> in the "setup" format _might_ be another obstacle to 3rd
> party ports of existing rpm packages.  Rpm could be enhanced
> to work with/around Window's file-copy semantics -- if by
> no other method that using "sysinternals.com" "movefile"
> utility which allows replacing of "in use" files (followed
> by a reboot to finish the install just as setup does).

Well, there have been recent discussion about reinventing setup.exe. 
Some suggested a front-end/back-end solution, where there is a GUI lying
on top of command line utilities to do the heavy lifting.  Others
brought up moving to existing packaging mechanisms like RPM or pkgsrc.

One thing is clear though, you can't just say "rpm is nice" and start
using that.  For one thing, the file replacement issue is nowhere near
as simplistic as you make it out.  "In use replacement" under windows
amounts to placing an entry in the registry telling the system to move
file A to file B upon next restart, and then put a copy of the updated
in-use file at location A and prompt for a reboot.  There's no magic,
there's no getting around the basic paradigm of windows filesystems that
require that all outstanding handles of a file be closed before it can
be deleted.  rpm packages assume that they can replace in-use files and
then HUP whatever had copies of those libraries in memory, and all will
be fine.  It just doesn't work the same under windows.

I can find no such utility "movefile" on sysinternals, but I think you
might be referring to something along the lines of the "inuse" utility
that is included in the windows resource kit.  Even still, there is no
way a tool like that could be depended upon for an open source project
like Cygwin.  Someone would have to write an implementation of the util
under a proper OSI license in order for it to be considered a necessary
and dependent part of the project.

It seems clear to most everyone that participated in those "setup.exe
sucks" threads that there must be some kind of "bootstrap setup" at the
very least, that is not dependent on the cygwin DLL that can
install/upgrade core packages.  You might be able to get away then with
using a richer environment (like tcl, perl, cygwin-ported-rpm, whatever)
for the other things.  But the point I'm trying to make here is the
following: Cygwin package management differs fundamentally from *nix, so
you can't just drop in *nix package tools without some modifications. 
Someone somewhere will have to write some code and until that happens
there will be no progress.

On top of that, I submit that it's not the binary package layout that's
an issue to getting more official packages.  The Cygwin packaging format
is quite simple, and if someone is motivated it should be rather easy to
take a source tarball that compiles cleanly and turn it into a cygwin
package.  The setup.hint authoring is close to trivial.  The thing that
seems to prevent people from contributing packages is the need for there
to be someone in the hotseat to take ownership of the package.  It seems
rather often that someone will say "I've been able to port app X to
cygwin without too much trouble but I can't commit to being a package
maintainer."  This has nothing to do with the details of the binary
package format used, and everything to do with redhat/cygwin drivers
wanting (...a very minor level of...) accountability for all official
packages.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/