Mail Archives: cygwin-apps/2001/11/20/20:02:12
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
>
- Raw text -