This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: setup.hint format change?
Christopher Faylor wrote:
> It provides a parser that I don't have to write for a fairly popular
> and well-understood markup language.
Great. Yet Another Markup Language to learn.
Oh...wait...Y.A.M.L. Right...</slaps forehead>
>>> I'm also wondering if we should just be using rpm and forgetting about
>>> our own package format.
Well, you don't get much more basic than a tarball (although, in fact,
our "package format" actually encompasses the setup.exe behavior w.r.t.
/etc/postinstall/* and /etc/preremove/*, setup's understanding about
cygwin mount points, and setup's ability to faithfully recreate windows
ACL's and replace in-use files...)
>>> Of course rpm comes with its own set of problems.
Yep. Every couple of years somebody returns to this idea, but the
difficulties are a bit daunting. Three choices:
(1) a full windows port of rpm
+ add all the setup.exe-style smarts --- non-cygwin understanding of
cygwin mount points and paths; replacing in-use files (but at least
rpm-native.exe itself won't "use" any cygwin files); ACL handling; etc)
+ and that's assuming you can get the "basic" functionality of rpm
working in a native win32 port.
Really, this is just too hideous to contemplate.
(2) cygwin rpm
+ much more complicated in-use file handling (because rpm-cygwin.exe
will rely on cygwin1.dll; popt.dll; etc etc
+ 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. Postponing postinstall scripts that depend on scheduled
file installation? Fuggetaboutit.
(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.
This bundle is distributed as the "installer" package, and is used to
update the "real" cygwin. Thus, no in-use files (except for the usual
suspects like ssh-agent and services).
The only problem with that is running post-install and pre-remove
scripts. All of the tools invoked need to use the same
cygwin-setup1.dll, otherwise the I/O redirection (via ptys) won't work.
It's like the hangs you sometimes get when invoking cygwin tools from an
MSYS shell, or vice versa. But the set of tools used by the universe of
postinstall/preremove scripts is fairly large -- to large to include as
part of a separately-compiled cygwin-setup1.dll-linked "installer"
bundle. And they'd all need tweaking to deal with the
sysroot-redirection thing.
> We've discussed RPM and other package managers here a few times. The
> biggest problem is that it or any other linux-based package manager
> requires the Cygwin DLL to work.
Yep. Scenario #2 above.
> The other problem is that the RPM database can get fairly big and can
> become corrupted.
Yep. But our simple setup.exe flat file can get corrupted too -- and
there was a database corruption bug in setup.exe quite recently. But it
was a lot easier to fix than ensuring "rpm --rebuild-db" Does The Right
Thing.
> I don't necessarily agree with that. I've used Debian and Gentoo and
> neither bothers me much.
Gentoo bothers me because I don't want to waste all my time compiling
every package. I suck as a maintainer, but I spend way too much time
compiling MY packages; I don't want to have to (re)compile everybody
else's packages too. (I know about the pre-compiled stuff, but that's
more of an afterthought to the gentoo system. Gentoo's "normal" mode is
ebuild == build it).
Debian...meh. The debian/* tree structure is clunky, but they've got
lots of nice maintainer tools to automate the management of that stuff.
But even so, dpkg and friends share the same problem as rpm: they of
necessity would rely on the cygwin dll.
> However, since Cygwin is owned by Red Hat I
> think it would be a little strange to be using anything besides RPM.
True that.
> Except maybe for setup.exe. That's nearly perfect of course.
But nothing beats B20.1's full.exe. Now THAT was perfection.
In answer to the question that spawned this thread: I don't have any
problem with changing the setup.hint format, so long as the transition
for existing packages is relatively automated.
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)?
--
Chuck