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: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Subject: Re: cygwin-apps Digest 2 Nov 2001 18:46:34 -0000 Issue 223
From: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
To: Joshua Franklin <joshuadfranklin AT yahoo DOT com>
Cc: cygwin-apps AT sources DOT redhat DOT com
In-Reply-To: <20011103052046.46423.qmail@web20008.mail.yahoo.com>
References: <20011103052046 DOT 46423 DOT qmail AT web20008 DOT mail DOT yahoo DOT com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/0.15 (Preview Release)
Date: 03 Nov 2001 22:27:43 +1100
Message-Id: <1004786864.1816.13.camel@lifelesswks>
Mime-Version: 1.0
X-OriginalArrivalTime: 03 Nov 2001 11:32:01.0821 (UTC) FILETIME=[27F454D0:01C1645B]

On Sat, 2001-11-03 at 16:20, Joshua Franklin wrote:
> > >So cygwin should depend on bash and shellutils.
> > 
> > How do you figure that?  
> Rob's right, it means setup.exe (for cygwin.bat and
> /etc/profile) should "depend" on the bash and
> shellutils packages. Hm. Evil thought--why not make
> the setup.exe auto-updating feature grab the file as
> /latest/setup/setup.tar.bz2, make the cinstall src
> available through setup.exe. In other words, make
> setup.exe a package. May be more complicated than it's
> worth, I haven't seen the auto-updating code.

Good idea. It's one discussed very briefly recently on the dev list, and
the actual concept behind setup auto updating. Baby steps though - once
setup is able to autoupdate we can do this.

> > If newlib-man is in "Base" then that's a bug in
> > setup.exe.  It is
> > supposed to be in "Doc" according to setup.ini.
> No no. I agree that both man and newlib-man are "Doc",
> but 
> 1. man is in only "Base" (where it's practically
> useless without groff and less)

I've already moved it to doc. And it doesn't matter where the dependent
packages are. The requires: field will automatically install those
packages as well.

> 2. newlib-man deals with "Devel" so maybe it should be
> listed there, too, or "Doc" as a seperate category
> should be postponed until more comprehensive
> documentation packages are available

By that logic, database should be postponed until there are more
database packages. IMO by having the _correct_ categories now we will
have the least confusion later.
 
> > It does raise the whole X11 issue, though.  
> Well, yes and no. The native-win version of rxvt 
> is a unique animal. I'd like it in "Base" since I use
> it by default, but barring a change in the setup.exe
> code that creates the Desktop/Start Menu
> links(desktop.cc I believe) this isn't going to
> happen. 
> But in either case "Util" seems more appropriate than
> "Shells"

I'm completly open on this. No preference (other than rxvt is not a base
package IMO). Shells/utils/even. Berlin - an X11 alternative - is in
misc in debian, so if I was to dictate, misc for rxvt would be my
choice.
 
 
> > > What is the consensus on the meaning of the 'base'
> > category?
> > > 
> > > Is it a) the _absolute minimum_ to run shell
> > scripts and invoke
> > > programs, or b) is it the core install for a
> > comfortable environment?
> Well, it might also be a choice to have "Base" left as
> it is and make a "Core" (instead of "Util"?) for what
> people probably expect (man, sed, which, etc).

The problem we have is that in debian, pacakges occupy a 2d space,
Priority vs Section.

Required|Imp|Std|Opt|Xtr are the priorities. A normal system has
everything of pri Req|Imp|Std, regardless of the "section". And Section
covers base/contrib/x11/sound etc.

We have plenty of time to tweak this.

I think the important question is:
if I as a new user grab setup.exe, run it, and just click next 7 times,
what do I end up with?

To that end, I'll agree that stuff *I don't think belongs in base*
should go there. However: if/when we get more flexable, I really think
we should revisit this.

That said, Joshua, can you visit the current setup.ini (I suggest
reviewing it by hand) and identify (based on Earnies previously linked
email) a good core list of packages that should auto install?

Please follow the following guidelines:
1) Don't include packages simply because a different package requires
them. (Requires: clauses handle that).
2) If setup.exe does something that needs the package there, then the
package is essential.
3) If a user expects it *no matter what* then it is a reasonable
candidate. 

If you can drop a list of what needs changing to this list, I'll give it
a once over, and so can every one else here, and all things going well
we can tidy up setup.ini and release this beast.

Rob