Mail Archives: cygwin-apps/2002/03/23/01:00:47

Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Date: Sat, 23 Mar 2002 01:00:28 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-apps AT cygwin DOT com
Subject: Re: Keeping base, adding standard.
Message-ID: <>
Reply-To: cygwin-apps AT cygwin DOT com
Mail-Followup-To: cygwin-apps AT cygwin DOT com
References: <FC169E059D1A0442A04C40F86D9BA76008AB7F AT itdomain003 DOT itdomain DOT net DOT au>
Mime-Version: 1.0
In-Reply-To: <>
User-Agent: Mutt/

On Sat, Mar 23, 2002 at 04:30:23PM +1100, Robert Collins wrote:
>>You're very unhappy with overloading categories while this is exactly
>>what I had envisioned when I suggested them.  And, I strongly disagree
>>with the above way of dealing with things.
>Why?  (Not trying to be dificult here).

Again, you're inventing another layer that I maintain will only confuse

What's the difference between the Devel category and the Developer
configuration?  I don't know what it is without thinking about it.  If I
am going to see two screens with the name "Developer" and "Devel" on
them, then I will be confused.  If we are only going to see one screen
then this is just a category.

If we need to redefine the categories into something called Workstation
and Server, I don't really have an objection.  Maybe the decision to
use Debian categories was a mistake for setup.exe.

>>I hope this doesn't mean that I have to go back to maintaining setup
>>but I don't think anyone is going to convince me that adding another
>>layer to the process is going to improve the user experience.
>You are of course welcome to resume the mantle anytime you feel the
>need.  I'm surprised that a discussion point would bring it up though.

I just meant that I am extremely unlikely to agree with you on this one.
So, I won't be willing to let setup grow in this direction.  I would not
blame you if you felt that your creativity was being hampered.

Maybe a way to resolve this is for there to be a testing version of
setup.exe where we can experiment with different user interfaces or
methods of doing things.  We could even put a link to the testing
version of setup.exe on the cygwin web site.

Then I can be proven wrong by people using a product with an alternate
interface.  I suppose this might require alternate versions of upset
and even changes in latest/contrib, though.

>certainly haven't threatened any "I won't do this" or suggested that
>it's "my way or the highway". And as no setup.exe changes are needed to
>do what you're proposing, my being setup maintainer is quite orthogonal
>to my point of view on that.
>> >OTOH leveraging dependencies via meta-packages to achieve it makes a 
>> >lot of sense to me, the question is how to present it to the 
>> user in a 
>> >meaningful way.
>> Sorry.  I don't know what this means.  If you mean allowing 
>> the addition of category names to dependencies then I think 
>> that's a great idea.
>I hadn't thought of that, but have no objection to it being done. I
>can't think of any immediate use for it though.

>What I meant was that if you want the user to select "Standard" and get
>the packages you listed as being 'standard' installed, creating an empty
>tarball that depends on those packages will do that.

Oh.  Ok.  I actually had an "All" package like this worked out at one
point.  I had modified upset to produce an All category which depended
on everything.  I never put it into operation though, obviously.

In this case, I thought I'd just add "Standard" to all of the
appropriate package categories.

The one missing thing however, is that I'd like setup.exe to auto-select
the Standard package.  There's no automatic way to do that, is there?

Maybe adding an additional "select these categories automatically" field
to setup.ini would be a way to remove this decision from setup.exe.


- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019