This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

   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

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?


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]