Re: ask-2.5.0 - a new package for review

[Elfyn McBratney <elfyn at cygwin dot com>]

On Mon, 30 Jun 2003, Jari Aalto+mail.linux wrote:

> * Sun 2003-06-29 Charles Wilson <cygwin@cwilson.fastmail.fm> list.cygwin-apps
> * Message-Id: <3EFF6D2A.1000907@cwilson.fastmail.fm>
> > 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
--