This is the mail archive of the
mailing list for the Cygwin project.
Re: package proposal update: suite3270
- From: "Peter A. Castro" <doctor at fruitbat dot org>
- To: cygwin-apps at cygwin dot com
- Date: Fri, 31 Oct 2003 17:17:29 -0800 (PST)
- Subject: Re: package proposal update: suite3270
On Fri, 31 Oct 2003, Corinna Vinschen wrote:
> On Wed, Oct 29, 2003 at 09:56:28AM -0800, Peter A. Castro wrote:
> > Hi All!
> > Due to "popular" suggestion (well, from Max and Chuck :), I've change the
> > names of the packages comprising Paul Mattes's 3270 emulator suite. All
> > individual emulator packages have been prefixed with 'suite3270'. This
> > will help group the suite together in the package selection list. This
> > was a minor change to the build scripts and thus a new source package was
> > created as well. Perhaps now someone will review (and vote for) it
> > (Please? Pretty Please!?).
> Ok, we have three votes, so I felt, I could review the package a bit.
A review!! Someone (Corinna) actually reviewed it!! Thank you!!
> > Here are the setup.hint files:
> > http://www.fruitbat.org/Cygwin/suite3270/setup.hint.suite3270
> The requires line uses the wrong package names. The leading "suite3270-"
> is missing. Besides that, if the base package already requires to
> download all other packages, the split would be unneeded. Did you
> actually intend that?
Ok, I knew there would be some confusion concerning this. Here's the
rational: The package "suite3270" is actually a super-package (Hmmm...
"Ssssuuuuuper-Package", I like the way that sounds :) which contains the
source for all of the emulators and provides a convenient way of
installing all products without having to hunt them all down individually
and selecting them (ie: the entire "suite" of emulators). Admittedly,
I'd changed the package names to prefix with 'suite3270-' to group them
togther, to make them easier to find, but perhaps that wasn't a good idea
after all. You can install each product independent of each other.
So, why isn't the source for each product with each package, you ask?
Because it came as a bundle from the source web site that way, and Paul
keeps them all in sync, so I was trying to preserve that thought by
keeping the source in one place, yet having each product's binary package
So, why the "-common" package, you ask? As I said, each product is
independent of each other. However, they all (except pr3287) install
some common files, which, if you installed the individually would overlay
each other, and upon removal of one package would remove those common
files for all. So, the build process moves those files which are
identical (common) into a separate package which is prereq'ed by each
package. It seemed like a good idea at the time.
> > http://www.fruitbat.org/Cygwin/suite3270/setup.hint.suite3270-common
> > http://www.fruitbat.org/Cygwin/suite3270/setup.hint.suite3270-c3270
> > http://www.fruitbat.org/Cygwin/suite3270/setup.hint.suite3270-pr3287
> > http://www.fruitbat.org/Cygwin/suite3270/setup.hint.suite3270-s3270
> > http://www.fruitbat.org/Cygwin/suite3270/setup.hint.suite3270-tcl3270
> > http://www.fruitbat.org/Cygwin/suite3270/setup.hint.suite3270-x3270
> The other setup files are ok, AFAICS. I'm just wondering what the base
> package is good for. All packages require the -common package, but none
> requires the base package.
Well, the super-package is just a container for the source and a way of
getting all packages installed at one shot. The build is actually kinda
turn-key, where you run the top-level script and it in turn runs the
scripts to build each product.
> > Here are the source and binary packages:
> > http://www.fruitbat.org/Cygwin/suite3270/suite3270-3.2.20-1-src.tar.bz2
> > http://www.fruitbat.org/Cygwin/suite3270/suite3270-3.2.20-1.tar.bz2
> > http://www.fruitbat.org/Cygwin/suite3270/suite3270-common-3.2.20-1.tar.bz2
> > http://www.fruitbat.org/Cygwin/suite3270/suite3270-c3270-3.2.20-1.tar.bz2
> > http://www.fruitbat.org/Cygwin/suite3270/suite3270-pr3287-3.2.20-1.tar.bz2
> > http://www.fruitbat.org/Cygwin/suite3270/suite3270-s3270-3.2.20-1.tar.bz2
> > http://www.fruitbat.org/Cygwin/suite3270/suite3270-tcl3270-3.2.20-1.tar.bz2
> > http://www.fruitbat.org/Cygwin/suite3270/suite3270-x3270-3.2.20-1.tar.bz2
> I really don't see what the suite3270-common package is good for. Couldn't
> that be better thrown together with suite3270? Both packages are really small
> and I don't see any gain in having a "base" and a "common" package.
> Besides that, the documentation is in all packages still in /usr/doc.
> Please move it to /usr/share/doc.
Ok, that I can do. I'd submitted this way back before the new share/doc
requirements had been instantiated and I haven't updated it yet :). I'll
> Another nit concerning the documentation. Each package creates its own
> documentation subdirectory right below /usr/doc. So after installing
> all packages, you have
> /usr/doc/suite3270-3.2.20 -- empty!
> /usr/doc/suite3270-common-3.2.20 -- empty!
(*sigh*) ... and correct the directory names, but this is starting to get
out of hand. I'm starting to think that naming the packages with a
prefix was a bad idea. Perhaps having them grouped together by name
isn't all that helpful.
> I would prefer to keep all documentation in one subdirectory
> and all the above subdirectories below that, instead of polluting the
> doc directory itself with so many subdirs for one base package.
> I would also prefer to have only one common README file under
> /usr/share/doc/Cygwin. Basically all these READMEs are the same, with
> just tiny differences. Why not just one file which describes the
> whole suite?
Hmmm... Well, since it's a requirement for each package to have a README,
I though it necessary to create a separate doc dir & README for each one.
See, I'm still working under the assumption that each emulator package is
independent of the other (expect for -common) and as such should be
treated separately, yet have a way of getting them all in one easy step.
Maybe I need to think a little more on just how this whole thing should
Perhaps it would be a good idea to see how other packages handle this
problem. Letsee... I've got source that's a bundling of separate
products, and each product has separate runtime requirements (curses,
tcl, X), so putting them into one package would then require way too many
other heavy packages to be installed as well (not a good thing). Plus,
each product has common files with the other products, so I have to allow
I could split the bundle into completely separate products and abandon
the whole "suite" idea, but I'd still have to contend with common files.
I'll have to do some research on the other packages.
Daniel, could you change the status of the proposal to "on hold" until I
get my thinking straight on this. Thanks!
> Otherwise the packaging looks ok to me.
Gee, only a few "minor" issues (d-P), but tanks for giving it a good
Peter A. Castro <email@example.com> or <Peter.Castro@oracle.com>
"Cats are just autistic Dogs" -- Dr. Tony Attwood