On Mon, 30 Jun 2003, Jari Aalto+mail.linux wrote: > * Sun 2003-06-29 Charles Wilson <[EMAIL PROTECTED]> list.cygwin-apps > * Message-Id: <[EMAIL PROTECTED]> > > Robert Collins wrote: > >> That said, I really don't think we want to formalise the package > >> creation script. If we -really- are heading to compatibility with any > >> existing format, surely our efforts are bested directed to achieving > >> that, not to (relatively minor) fiddling within our adhoc format. > > > > Agreed. > > > > In my dream world, setup.exe will interoperate with both deb and rpm > > packages. There will be tools (or libraries) that allow synchronization > > of the various databases (deb's installed, /var/rpm/*, and > > /etc/setup/*). Setup.exe will update all of them. Cygwinized rpm and > > apt tools will update all of them. > > > > And we will be able to use any of those tools to install stuff: setup, > > rpm&derivatives, apt&derivatives. > > > > And we (package maintainers) will be able to use debian or rpm tools to > > package our stuff, and we'll eventually migrate away from tarballs. > > > > That's my dream. But it'll take years to get there, and I'm not in a hurry. > > > > To tell you the truth, I think a nice interim step would be a tool of > > some sort that leveraged deb/rpm packages, to create setup-compatible > > tarballs, complete with taking rpm-style post/pre scripts and "putting > > them in the right place" so that setup will do the right thing. > > > > Then, for instance, we could simply use rpm tools to create an rpm -- > > and then run rpm2setup to create the distributable tarball and src tarball. > > > > Ditto .deb. > > That would be great if we could use standard .deb or .rpm packages. > > > I think this is a better path to take than worrying about cygbuild vs > > mknetrel vs generic-pkg-script vs.... > > It was not my purpose to propose any "new build" method. What I did > was simply taking the basic build script and played with it for a > while. To my eyes the basic sh-script was not adequate, because for > each package it needed changes. In the end you woudl have to maintain > sevral build-scripts and change them for every new release. > > So to automate porting from various source (tar.gz, .deb, and other > diverse packages I encountered), I just "updated" the basic script to > use bash instead of sh and added perl logic + wrote the manual how to > use the toll if anyone was interested in trying. Currently it's > available in full Cygwin Net release packaging format: both source and > binary. I'll try to set up a CVS tree, so that anyone can access > the sources easily and propose changes. > > The cygbuild only intends to provide more easy automation of the > porting process. I do not know how other maintain their packages, but > my goal is to keep things as easy as possible. Any automation, that > would be common to all ported packages is therefore alwasy a plus. > > It is true, that I have slightly extended the basic method to use > > external scripts > > But they are purely optional and only needed is the package being > ported is tweaky and diffiucult. External user written scripts give > cygbuild a modularised extensibility. It's like. > > If standard cygbuild program cannot handle it, then this package > is too complex for automatic tool. Let user guide those steps > what are tricky. Sometimes it's just "conf", othertimes it's just > "install" step that needs a tweak. > > It's seldom all the phases, conf, build, install, package. > In that case, It's probably not worth porting the package or to > use cygbuild at all. > > I'd like to see more packages included in cygwin and it seems that > now, after removing lot of bugs from cygbuild, I can concentrate to the > porting and not to the details of packaging itself.
Jari, I'm sure I'm not the only one who appreciates all of the *hard work* your doing, but, IMO until a package, self-written or not (i.e., cygbuild), has lived through it's todler years (OK, in developement years :-), it's not ready to be included in a deistribution. This is just following the rules set-out. Packages like cygrunsrv and cygutils, for example, were written for a purpose, that purpose being Cygwin. The point is they were not included straight away. What I think would be a really good idea, as Chuck, Max or..said, would be to try and get your changes into either the generic-build-script or mknetrel. All elements of cygbuild can be done without perl (using sed, for example). And build-scripts are designed to be light weight! If you submit patches to add your improvements to one of the already in-place systems, I'm sure it's maintainer will consider adding them. Elfyn --
