On Fri, Oct 31, 2003 at 05:17:29PM -0800, Peter A. Castro wrote: > On Fri, 31 Oct 2003, Corinna Vinschen wrote: > > > 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... > [...] > 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.
But that's not the problem. > So, why isn't the source for each product with each package, you ask? I never asked this. This is a good thing, IMHO. > 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. It's still a good idea. I just don't think the super-package idea is a good one. What do we have? 5 packages with a common set of files. So why not keep the common files together in the base package, which then is not a *super* package but just the container for the common files and the name and container of the source package. > > 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! > > /usr/doc/c3270-3.2.20/ > > /usr/doc/pr3287-3.2.20/ > > etc. > > (*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 don't think so. Grouping them together using the suite3270 prefix is a good idea, IMHO. > > I would prefer to keep all documentation in one subdirectory > > > > /usr/share/doc/suite3270-... > > 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, This is a rule of thumb, not a slavish one. The package is "the suite of 3270 emulators". Put one README in the base package and you're done. > I though it necessary to create a separate doc dir & README for each one. Just don't take the rule too literally. > 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 But independence of binary packages don't mean they are entirely independent products. They share a common purpose and as such they will be treated by us dumb folks. Btw., I tried a test of the binary c3270.exe. From the man page I got the impression, the emulator should be able to connect to any telnet server. I don't have a OS/390 machine handy so I used the telnet server on Cygwin to connect to. But it fails. It connects and it shows a login prompt. Then the password is requested by login(1), the same as running a standard telnet session. But for some reason I'm always getting a "Login incorrect" message. When connecting with a normal telnet client, I can login, so I don't quite understand how this is supposed to work. Any hint? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:[EMAIL PROTECTED] Red Hat, Inc.