This is the mail archive of the
mailing list for the Cygwin project.
Re: cygwin-apps Digest 2 Nov 2001 18:46:34 -0000 Issue 223
- To: Joshua Franklin <joshuadfranklin at yahoo 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>
- Date: 03 Nov 2001 22:27:43 +1100
- Cc: cygwin-apps at sources dot redhat dot com
- References: <firstname.lastname@example.org>
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",
> 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
> But in either case "Util" seems more appropriate than
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
> > > 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
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.