RPM's require to much knowledge of setup to port easily

[Linda Walsh]

Igor Peshansky wrote:
> Do you mean that you used Cygwin's rpm package to produce that RPM?
yes.


>>    I'm sure there's some good reason for converting all
>> packages to yet another installer, but I'm not sure I know
>> what they are.  One side effect, though -- it can  put a
>> damper on porting programs over when most (or all) of the
>> work is in converting to the a different installer.
> 
> Technically, nothing prevents you from shipping a Cygwin package (which is
> just a .tar.bz2) that contains only the Cygwin binary RPM and the
> postinstall script that invokes "rpm" to unpack that binary RPM (as long
> as that package also "requires:" the "rpm" package).  You'll also need to
> build a manifest of all extracted files and have a preremove script that
> cleans those up.  See the gcc-mingw-core package for an example of a
> similar approach.
---
	I wasn't thinking so much for my own devious purposes, but if
someone wanted "logrotate", I could have spoke up on the list and
announced it...but if it isn't in some common cygwin-ish location,
rpm packages will be pretty random.

> 
> What you will lose with the above is the ability to list and search
> package contents via cygcheck and the online package search.
---
	I also miss the ability to do an rpm -qi <packagename>, or
rpm -qf <file>, or to find a version rpm -q <package>.  One problem of
producing useful RPM's is that non of the base files (if/then...cp, gzip)
are installed in the RPM database, so it's impossible to setup real
prereqs.

> Incidentally, one of the things we should teach setup and cygcheck to do
> is look at the manifest files produced by postinstall scripts and include
> those in the file lists of the package.  I'm sure it would be easier to do
> than add full dpkg or rpm support to setup.exe, and would be a good way
> to familiarize yourself with the code of setup/cygcheck.  As usual, PTC.
---
	Thanks...but here again, we've come full circle.  I have an existing
cygwin RPM, but to make it available to the masses, (as much as any other 
setup-based program), I have to not only learn the setup format, but the
structure of the source code itself.  I'd say that's a barrier to people
providing ports.

	Unfortunately, I have a less than ideal Win development setup.  It
can do small things, but with a Mobile-P-III on a 5-6 YO laptop, we aren't
talking hyper speed or resources.  I've, moreo than once tried to setup
a development env for cygwin setup and the cygwin dll, with an emphasis on
a cross-compile from linux, since I also have access to a slightly faster
linux machine, but it's as old as the laptop, it's only faster because it
was a workstation model when it was new.

Every time I've tried to setup an environment, I run into items I don't
have in my environment that the instructions somehow assumed were there.
I fix one thing, and another pops to the top of the list to block progress.
I lose interest.  Due to various reasons, my development cycle(s) are
slower than they used to be, and are also limited in time (correctable, _maybe_,
with spinal surgery...something I'm not wanting to rush into).
It puts a kink in some of my more favorite activities.

	Regardless of my specific circumstance, it still seems there is
a lot of work to be done before RPM's could be distributed as part of cygwin.

	I still don't get all the reasons behind forcing everyone into a
new format.  Is it just a power trip or what?  The issue of active files not
being over-writeable, could be handled transparently by the cygwin layer, from 
what I can tell.  At least on NT based systems (haven't tried it under Win9x 
type systems), a delete of an active file, instead of failing could rename
the active file to a suitably cryptic nanem ".deletedfile#######", and the
delete commands could be entered into OS's pending fileops for when the user
next reboots.  What other reasons would we have for not using RPM?

-l

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/