Re: ask-2.5.0 - a new package for review

[letters at hotpop dot com (Jari Aalto+mail.linux)]

* 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