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/
