This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: setup.hint format change?
Charles Wilson wrote:
setup's understanding about
cygwin mount points, and setup's ability to faithfully recreate windows
ACL's and replace in-use files...)
Wouldn't cygwin1.dll give rpm.exe these abilities?
(2) cygwin rpm
+ much more complicated in-use file handling (because rpm-cygwin.exe
will rely on cygwin1.dll; popt.dll; etc etc
Can we not assume that some in-use files are okay to keep using? Is it
really necessary that upgrading a running Cygwin system needs to use a
new cygwin1.dll?
I realize that this means mandating a reboot to finish the install, but
that's what happens today already.
+ stock rpm doesn't have the ability to "pause" and tell the user to
go fix an in-use file problem; or to "schedule" later installation of
in-use files.
That could be patched in, using code lifted from setup.exe.
Postponing postinstall scripts that depend on scheduled
file installation? Fuggetaboutit.
Can we postpone the script execution, too?
There have also been historical threads about giving setup.exe the
smarts to shut down all cygwin1.dll users gracefully during the
installation.
(3) One idea that was floated was a "mini-distro": a specially-compiled
version of the cygwin dll (cygwin-setup1.dll) with separate shared
memory region etc, and the rpm installer and its other dependent
libraries are all linked against that. BUT, they use a sysroot-style
redirection to the "real" installation location, rather than to their
own tree, when unpacking.
I don't see the need for this. setup.exe's dependent rpm.exe should be
able to use any cygwin1.dll. The DLL's file name hasn't changed because
old binaries can continue to use it; the interface is stable. Don't we
just have to avoid using new cygwin1.dll interfaces in rpm.exe?
It should be quite rare for a cygwin1.dll to have a bug so severe that
the system can't even be upgraded by an rpm.exe using the old DLL.
Were you planning on keeping the current structure (separate setup.yaml
files for each .tar.bz2), or switching to a single setup.yaml for an
entire set of related tarballs (e.g. all tarballs that derive from the
same -src.tar.bz2 package)?
Now *that* would be a good use of a hierarchical file format.