This is the mail archive of the 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-4.1 port to cygwin available

> Peter Ring wrote:
> > There's substantial evidence that RPM based distribution of Cygwin is
> > feasible:
> >
> >
> >
> > Just in case you don't read Japanese, go directly to the FTP site:
> >
> >
> (In case anyone was wondering, Peter was one of those hardy souls
> working on porting rpm 'back in the day' -- IIRC Peter was working on
> early 4.0.x versions...)
> Yes, an RPM-based cygwin is feasible -- but the last time I looked, most
> of the competitors said something like: "First do (X) to install a basic
> cygwin system, and then use this tarball of rpm.exe, run rpm --initdb,
> then use rpm to install and/or update other parts of your system"
> Where (X) is "unpack a tarball" or "piggyback off setup.exe and only
> install these three packages" or somesuch.
> While *feasible,* that's not really *practical* as a "complete"
> distribution.  Further, none of the schemes out there were capable of
> updating the cygwin dll itself -- because rpm.exe uses it.  Nor could
> they update any other in-use files.
> However, things may have changed over the years. I dunno, and I'm too
> lazy to check now. :-)
> Personally, I'd welcome an official setup-installable package providing
> rpm.  Here's why:
>    1) we'd probably see a number of folks -- those who don't want to
> permanently maintain a package, but want to provide it for people to use
> -- who'd choose to pack their contribution as rpms.  (Preferably,  these
> ad-hoc rpms would go somewhere like /usr/local or /opt/ or ANYWHERE
> except /usr and /usr/X11R6/ ).
>    2) as these numbers grow, folks might begin wondering how to (and
> provding code for) help setup.exe and rpm coexist -- updating each
> other's databases, maybe even linking setup.exe against librpm, etc etc.
>   Of course, this requires that someone really really smart figure out
> the best way to create a "native" port of librpm -- that can still
> figure out where /var/cache/rpm and /etc and suchlike are really
> located...
This goes back to that other thread of figuring out where / is from a
non-Cygwin application.
There would still have to be some auxillary program to set / in the first


Unsubscribe info:
Bug reporting:

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