X-Spam-Check-By: sourceware.org
Message-ID: <448C73CA.60703@tlinx.org>
Date: Sun, 11 Jun 2006 12:49:30 -0700
From: Linda Walsh <cygwin AT tlinx DOT org>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: RPM's require to much knowledge of setup to port easily
References: <061020062022 DOT 10945 DOT 448B29F200067FE000002AC122068246930A050E040D0C079D0A AT comcast DOT net> <448B643D DOT 6040401 AT tlinx DOT org> <Pine DOT GSO DOT 4 DOT 63 DOT 0606111355460 DOT 25353 AT access1 DOT cims DOT nyu DOT edu>
In-Reply-To: <Pine.GSO.4.63.0606111355460.25353@access1.cims.nyu.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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/