packg mngmnt model & other cygwin package releases...(where did they come from?)
Fri Feb 25 11:08:00 GMT 2005
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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin