setup.hint format change?

[Warren Young]

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.