This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: setup.hint format change?
Christopher Faylor wrote:
What problems are you trying to solve?
The one in the paragraph that you snipped.
I saw that you want a database, but I don't understand why. What does
this give you?
I don't doubt that there's a good answer. It's just that most of us
don't deal with upset, so without knowing what its problems are, there's
a limit to how informed our answers to your RFC can be.
RPM maintainers aren't
generally very good at thinking about portability. It's possible that
this has changed since 2006 but I suspect that it is still a problem.
Yes, this is still correct. I've never gotten a SuSE binary RPM to work
correctly on a Red Hattish system, for instance. It's rare that you can
even get a .src.rpm from another distro to rebuild without changes.
However, starting from someone else's spec file does give one a leg up
on that porting task.
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.
Can't we solve this with a little bootstrapping?
Today's setup.exe already has to install cygwin1.dll and sh.exe. Those
two files, rpm.exe, and whatever else they need can go into a fairly
small versioned tarball. setup.exe downloads setup.ini (or its
replacement) early on as it currently does, then checks to see what
bootstrap tarball version is installed (if any) and downloads and
unpacks the current one if needed. From that point on, setup.exe can
just call out to rpm.exe repeatedly to complete the installation.
setup.exe can remain ignorant of the RPM file format. It can still get
package info from the new setup.ini, extracted from the RPMs by this
"upset v4" you're talking about. It can do that either with rpm(1)
queries, or directly with librpm or something like this:
http://search.cpan.org/~rjray/Perl-RPM-1.51/RPM.pm
It's possible that by offloading the package management to rpm.exe,
setup.exe could actually get smaller.
The other problem is that the RPM database can get fairly big and can
become corrupted.
As for the size, I checked one box here, and it's 53 MB. Big, sure, but
four orders of magnitude smaller than the smallest hard disk you'd put
into a new system.
The corruption issue I addressed previously: I haven't seen that happen
since switching fully to journaled file systems. If it does, it doesn't
break what's already installed. It just means you have to fix the DB
with rpm --rebuilddb before you can make changes to your installation.
And think of the benefits. In addition to the day-to-day system
management benefits, I figure about 90% of the uses of cygcheck could be
replaced by a single rpm query command. The results of, say, "rpm -qi
rsync" are easier for Joe User to paste into an email than figure out
how to attach cygcheck output, and it's easier to read, too.
I don't think we've yet reached the state of package manager perfection.
Except maybe for setup.exe. That's nearly perfect of course.
Speaking thereof, setup.exe is a natural candidate to offer yum-like
services, relying on rpm.exe as yum does to do its bidding.
At the end of the setup process, setup.exe could copy itself into
Cygwin's bin directory, perhaps renaming itself along the way. Call it
cygsetup.exe.
When it sees that it was launched as cygsetup, it runs in a command line
mode patterned after yum. On being asked to install a new package, it
loads all the info from the previous interactive run -- setup.ini, the
last-used mirror, etc. -- and uses that to figure out how to do what you
asked, with as little user interaction as possible.
I can't count the number of times I've installed Cygwin afresh on a new
system, then had to relaunch setup.exe multiple times and walk through
the GUI accepting defaults and digging through the package tree to
install yet another package I forgot to select the first time through.
It would be so much nicer to just say something like "cygsetup install
openssh", then go get some tea while it downloads the package and its
dependencies, and installs them.