Mail Archives: cygwin/2006/06/11/15:49:46
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/
- Raw text -