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
From: "Paul G." <pgarceau AT qwest DOT net>
Organization: New Dawn Productions
To: cygwin-apps AT cygwin DOT com
Date: Tue, 20 Nov 2001 16:47:11 -0800
MIME-Version: 1.0
Subject: Re: -src package standard: proposal #5 and #5a
Reply-to: Paul Garceau <pgarceau AT qwest DOT net>
Message-ID: <3BFA890F.18658.E5AD8D@localhost>
In-reply-to: <20011120025230.GA9596@redhat.com>
References: <OE45lk5wQlqlTPX4R0P00013cf7 AT hotmail DOT com>
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body

	Seems like things are getting quite complex here, I wonder whatever 
happened to "Ye Olde Kiss"?  Been following this as I have been able 
to, and would like to suggest a possible solution.

	I agree with cgf, these setup discussions are becoming tedious.  As 
much as I support the collaborative approach, there still needs to be 
someone who is authorized to make a final decision.

	In this case, I would think that Robert Collins (maintainer of 
setup.exe), as a sort of reward, should be given this finalization 
authority if that is what he desires.  Robert has done fantastic work 
on updating setup.exe, imho, and should, at the very least, be 
acknowledged for his effort and time in doing so (Kudos to those who 
have).

	Now, to the issue at hand:

	Perspective:

	In the old Cygwin distributions (v17/v18), there were two types of 
archives you could download, a) base/user and b) full.  As I recall, 
you had to choose, before downloading, which one you wanted.  You 
accomplished this by simply selecting the source code collection, in 
the form of an archive, from the respective ftp: site.

	Source code downloads were fairly straightforward.  Each source 
package archive included its internal dependencies (Cygwin API source 
being kept separate from the rest of the source code available).

	Since we are talking about -src package standards, I am having 
difficulty understanding why we can't just select the necessary source 
based on the pre-defined source code dependencies of the source code 
collection in question.

	Current Categories, for their part would remain as they are.

	Basic dependency, at least as far as source code is concerned is 
simple:  The cygwin API source collection is required.

Base Definition:

	Cygwin API Source collection is that source collection which is  
required to generate a minimal working version of the Cygwin API".  
This might also be called "Base (or basic) Cygwin API Source Code 
Collection.

	If you already have the Cygwin API source collection, then the 
setup.exe senses that the Cygwin API source collection is installed and 
presents the end-user with the option to (keep/skip) what you already 
have OR a third option ([keep/skip]+empty box under Src) IFF the cygwin 
API source collection referenced is outdated or an older source code 
collection revision.

	Now you've selected the basic cygwin api source (Base?) update by 
ticking the Cygwin API Src box in Setup.exe.

Specific Source Collection Definition:

	You want to build a particular utillity, eg. bash.  You find the 
category which contains bash, then set the src box (tick) which 
automatically overrides the (keep/skip) selection based on the source 
dependencies (eg. bash) by auto-ticking all of the dependent source 
code collections required to build a working version of the utility in 
question (eg. bash).

	Checking or having previously checked source code collection 
dependencies, Cygwin setup downloads/installs the latest source code 
release archive for bash AND makes available the option to (keep/skip) 
XOR update the Cygwin API source code via GUI update by auto-ticking 
Src box for Cygwin API source code collection within the Cygwin Setup 
GUI.

Complete Source?

	Finally, for those who don't care about dependencies, and typically 
download "All" the source, there is added a new category defined/called 
"Cygwin -- Complete Source" (for lack of a better description).

	By electing to download/install all of the source, you inform 
setup.exe to automatically dowload/install all the latest source 
collections/archives (forces auto-ticking of all of the dependent Src 
or "source code collection" boxes) to your hard drive.

	If the person selecting "All" from "Cygwin -- Complete Source" 
category chooses to, they can then, manually un-tick those source 
packages which they do not want.

	For those who only want specific source collections, all they need to 
do is click on the appropriate Src box in order to make available the 
dependent source code for the particular item which they, in fact, do 
want (eg. bash, vi, etc.) based, of course, on the items' internal 
source code dependencies (whether it be bash, vi, or something else 
entirely).

	Paul G.

On 19 Nov 2001 at 21:52, the Illustrious Christopher Faylor wrote:

> On Tue, Nov 20, 2001 at 01:41:43PM +1100, Gareth Pearce wrote:
> >> Thanks for playing along.  In other words, this problem has nothing to
> >> do with what we're talking about.
> >>
> >> We could have the problem of conflicting files no matter what we do.
> >>
> >> You're arguing that we can't use the word "All" because someone will
> >> be upset when gvim isn't installed.
> >>
> >> Ok.  I'm arguing that you can't use the word "Workstation" because
> >> someone will be upset when gvim isn't installed.
> >>
> >> There's no difference.
> >
> >I am going to disagree here.  When someone is upset because "All" doesnt
> >install gvim, I would think they have a point.  When someone is upset
> >because "Workstation" doesnt install gvim, I dont think they have a valid
> >point.
> 
> I already said we don't have to call the category "All".  Did you
> miss that part?
> 
> The fact that we have something called a "meta-package" is irrelevant.
> The problem of package conflicts has no bearing *at all* on this.
> 
> You could just as easily have categories called "Work Station" if you
> wanted.
> 
> This proposed plan would first present you with the opportunity to
> select "Workstation" and then you'd get another screen.  Hmm.
> Development.  Does this mean "Workstation Development"?  Does it mean
> "All of the development tools that make sense for a Work Station"?
> 
> >Workstation is a custom set of choices, its going to not nescerly do
> >what you want... you fine tune such things yourself post fact.  All -
> >implies all ... I dont really see anyway of it meaning anything else.
> 
> Sigh.  Somebody shoot me, please.
> 
> I am really sick of these setup discussions.
> 
> cgf
>