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


On Sun, Jun 11, 2006 at 12:49:30PM -0700, Linda Walsh wrote:
>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.

There is no one-to-one equivalent to "rpm -qi" but "rpm -qf" is equivalent
to "cygcheck -f" and "cygcheck -c <packagename>" will give you the package
name and version.

>>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.

It's not clear that you really understand that 1) cygwin "packages" are
just tar files and 2) there is already a way to do some of the things
that you have mentioned.

I wouldn't mind moving to a more accepted packaging format but I don't
think that doing so would make people more inclined to contribute
packages.  A setup.hint file is much simpler than an rpm spec file so,
unless you actually already understand rpm spec files, moving to rpm
could actually add an additional burden to package submission.

>I still don't get all the reasons behind forcing everyone into a
>new format.  Is it just a power trip or what?

Actually, the "new" (i.e., five+ year old) format was imposed on us by
the Trilateral Commission.  It was one of several initiaitves intended
to draw focus from the Y2K election fixing and the Hollywood-staged moon
landing.  I probably shouldn't divulge this, but this was a joint
directive signed by both Elvis Presley and Henry Kissinger.  So, as you
can see, we really had no choice in the matter.

cgf

--
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/


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