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: [UPDATE] Pending package status (25 Jun 2003) (cygbuild)

* Wed 2003-06-25 Elfyn McBratney <> list.cygwin-apps
* Message-Id: <Pine.CYG.4.55.0306251650490.3408@ellixia>
> On Wed, 25 Jun 2003, Elfyn McBratney wrote:
>> 10. glimpse
>> date   : 02 Jun 2003
>> version: 4.17.4-1
>> status : on hold
>> notes  :
>> votes  : 3 (Christopher, Gerrit and Joe)
>> url    :
> As noted in one of the notes above, Jari recieved acknowledgement
> from the glimpse maintainer regarding licensing. As the upstream
> maintainer has OK'd this distribution as long as a file regarding
> corporate usage (license note?) is inserted into the binary package,
> can this package be taken "off hold"? As long as the file is
> inserted into the package?
> I'm wondering.. Will it conflict if their license isn't GPL or OSD
> compatible?  Regarding linking it with Cygwin and thus automatically
> making this distribution of glimpse GPL'd?

As far as I understand, Glimpse developers have all the time favoured
Open Source. What comes to the licencing, it's wording is more like
"academic" than corporate if you look at the licence file and its

The current installation method automatically provides additional file
that makes the commercial usage more explicit as long as it is not in
the core glimpse distribution.


>> 18. cygbuild
>> date   : 12 Jun 2003
>> version: 2003.0612-1
>> status : not reviewed
>> notes  :
>> votes  : 0
>> url    :
> Do we go with the status quo with this package? IMO, and this isn't
> personal, we should stick with the defined methods for creating
> packages for the Cygwin distro.

Here is some more background:

- It's based on the 'sh' script provided at "Here is an example build script ..."

The methodology the script used looked interesting (deriving package
attributes form the script name), but I thought it could be improved
so that the manual work (editing the script every time a package was
ported), could be reduced to minimum. It started from small
modifications but spread to a complete "swiss army knife".

The current implementation extends the "Here is an example build
script ..." in following way:

- The script is self standing "program" and sniffs environment form
  current directory (you have to have unpacked package to package-NN.NN/
  directory and chdir inside it)
- It knows about debian package specialities (.orig. in name, not -src)
- It knows how to port perl packages. (Makefile.PL and some other things)
- It knows how to copy packages doc/* directory contents (drops .man, .1
  etc. files)

The biggest change is the added delegation and porintg support by
external scripts:

- If iser has written CYGWIN-PATCHES/, that is called from 
  the program
- Likewise for, etc.

So if the script's "standard" porting does not work, it's very eay to
port using separate scripts that user can write and maintain.

    See manual section "Directory package-NN.NN/CYGWIN-PATCHES/ and
    optional scripts"

The build script has been greatly improved since the initial release.
Here are the new URLs.


Swatch  @time
Convert @time

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