Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com Subject: Re: setup testers wanted From: Robert Collins To: Joshua Franklin Cc: cygwin-apps AT cygwin DOT com In-Reply-To: <20011102031557.74466.qmail@web20009.mail.yahoo.com> References: <20011102031557 DOT 74466 DOT qmail AT web20009 DOT mail DOT yahoo DOT com> Content-Type: multipart/alternative; boundary="=-AGWV0IGiVefILzn4DmqM" X-Mailer: Evolution/0.15 (Preview Release) Date: 02 Nov 2001 18:29:47 +1100 Message-Id: <1004686188.6333.16.camel@lifelesswks> Mime-Version: 1.0 X-OriginalArrivalTime: 02 Nov 2001 07:34:02.0962 (UTC) FILETIME=[BEAD9B20:01C16370] --=-AGWV0IGiVefILzn4DmqM Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2001-11-02 at 14:15, Joshua Franklin wrote: > > This is the same bug as has been reported twice. > Sorry, I'm suscribed with the digest version. I should > have waited until the next digest came in to avoid 'me > too's. Heh, no problems. When I'm on a digest list, I usually check the web archive to avoid that happening - as an alternative to waiting. > > > Also, this pertains to what I say below, but > > > shellutils really ought to be in "base" so > > > /etc/profile can do $(id -un) > > This is a packaging issue, setup.exe is data driven > So cygwin should depend on bash and shellutils. No, the package that contains /etc/profile (setup.exe :}) needs to depend on shellutils. Bash is irrelevant - /bin/sh is ash. Now, for things that setup.exe depends on, they go into the base category. > > rxvt and tcsh are not part of base, and should not > > be. Where do you > > suggest they go if not in shells? > ash, bash, and tcsh are shells. rxvt is I guess an > xterm. So we need an "xterm" (more confusion about > X11) or "misc" or something. Is that "utils" category > from Debian as Chris mentioned? Is there a URL for > this Debian packages standard we are ripping off? Or > could stuff like clear and rxvt be lumped in "misc"? We're not quite copied from debian. Debian has 'sections' and priority. (IIRC). See the debian policy document for more info. utils is a catchall, it's got an X file and application maanger, a netscape file, a replacement for w - all sorts of stuff. > > > newlib-man doesn't cut it. Put it in devel. > > It is a documentation package isn't it? > So it man, then. What's it doing in "base" (see below > about "base")? I suggested devel since all the pages > are in man 3. We don't have a section called man. IMO we don't want one. Most package documentation will include man pages AND html AND README's and possibly more. 'man' is too limiting. > > > f. Unless those man pages in base are preformatted > > (in > > > which case they should be in catx, not manx), it's > > not > > > going to do a lot of good without groff. > > > > Good point. > And less. man won't work without that or a link to it, > I just found out from an attempted minimal install. Please see my forwarded message setup.ini - some points where I discuss the base and required categories. man is not a base tool. > > Note that base != user friendly install. Base is the > > core stuff required > > for cygwin to work. > Hm. I thought setup.exe was supposed to be the "user > friendly install". And, I thought stuff required was > just cygwin and a shell (bash by default, but you > could mess about and get ash or tcsh to work). ash is the default /bin/sh. (but thats a side issue). the point about user friendly installs is that folk still want flexability. The less absolutely essential packages the better from that point of view. Why have bash if you are happy with ash + tcsh. The absolute minimum grabbed by running setup will be a functioning unix environment with few tools. We can have empty meta packages to provide various preset configurations. These packages are cross-category tools. Perhaps a category called 'presets' or 'tasksets' should be created to hold these, and a couple of inital ones created? All thats needed to create one is a tarball with nothing in it (except, say, /etc) and a setup.hint file. (see www.cygwin.com/setup.html for doco on setup.hint files). 4. What I'm proposing. A user friendly GUI for installing with, and some useful meta packages to pull in a user friendly environment - note the distinction. We cannot completely avoid cygwin AT cygwin DOT com questions - if we don't have (say) gcc in the default, we'll get questions "I installed cygwin, gcc says it's not found". And vice verca, if gcc is automatically installed "Why does it install gcc, I just want postgresql". Rob --=-AGWV0IGiVefILzn4DmqM Content-Type: text/html; charset=utf-8 On Fri, 2001-11-02 at 14:15, Joshua Franklin wrote:
> > This is the same bug as has been reported twice.
> Sorry, I'm suscribed with the digest version. I should
> have waited until the next digest came in to avoid 'me
> too's.
Heh, no problems. When I'm on a digest list, I usually check the web archive to avoid that happening - as an alternative to waiting.
> > > Also, this pertains to what I say below, but
> > > shellutils really ought to be in "base" so
> > > /etc/profile can do $(id -un)
> > This is a packaging issue, setup.exe is data driven
> So cygwin should depend on bash and shellutils.
No, the package that contains /etc/profile (setup.exe :}) needs to depend on shellutils. Bash is irrelevant - /bin/sh is ash. Now, for things that setup.exe depends on, they go into the base category.
 
> > rxvt and tcsh are not part of base, and should not
> > be. Where do you
> > suggest they go if not in shells?
> ash, bash, and tcsh are shells. rxvt is I guess an
> xterm. So we need an "xterm" (more confusion about
> X11) or "misc" or something. Is that "utils" category
> from Debian as Chris mentioned? Is there a URL for
> this Debian packages standard we are ripping off? Or
> could stuff like clear and rxvt be lumped in "misc"?
We're not quite copied from debian. Debian has 'sections' and priority. (IIRC). See the debian policy document for more info. utils is a catchall, it's got an X file and application maanger, a netscape file, a replacement for w - all sorts of stuff.
 
> > > newlib-man doesn't cut it. Put it in devel.
> > It is a documentation package isn't it? 
> So it man, then. What's it doing in "base" (see below
> about "base")? I suggested devel since all the pages
> are in man 3.
We don't have a section called man. IMO we don't want one. Most package documentation will include man pages AND html AND README's and possibly more.
'man' is too limiting.
 
> > > f. Unless those man pages in base are preformatted
> > (in
> > > which case they should be in catx, not manx), it's
> > not
> > > going to do a lot of good without groff. 
> > 
> > Good point.
> And less. man won't work without that or a link to it,
> I just found out from an attempted minimal install.
Please see my forwarded message setup.ini - some points where I discuss the base and required categories. man is not a base tool. 

> > Note that base != user friendly install. Base is the
> > core stuff required
> > for cygwin to work. 
> Hm. I thought setup.exe was supposed to be the "user
> friendly install". And, I thought stuff required was
> just cygwin and a shell (bash by default, but you
> could mess about and get ash or tcsh to work). 

ash is the default /bin/sh. (but thats a side issue).
the point about user friendly installs is that folk still want flexability. The less absolutely essential packages the better from that point of view. Why have bash if you are happy with ash + tcsh.

The absolute minimum grabbed by running setup will be a functioning unix environment with few tools.

We can have empty meta packages to provide various preset configurations. These packages are cross-category tools. Perhaps a category called 'presets' or 'tasksets' should be created to hold these, and a couple of inital ones created?

All thats needed to create one is a tarball with nothing in it (except, say, /etc) and a setup.hint file. (see www.cygwin.com/setup.html for doco on setup.hint files).
4. What I'm proposing. A user friendly GUI for installing with, and some useful meta packages to pull in a user friendly environment - note the distinction.

We cannot completely avoid cygwin AT cygwin DOT com questions - if we don't have (say) gcc in the default, we'll get questions "I installed cygwin, gcc says it's not found". And vice verca, if gcc is automatically installed "Why does it install gcc, I just want postgresql".
Rob
--=-AGWV0IGiVefILzn4DmqM--