setup.hint format change?

Warren Young warren@etr-usa.com
Wed Dec 31 10:00:00 GMT 2008


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.



More information about the Cygwin-apps mailing list