Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm Sender: cygwin-apps-owner AT cygwin DOT com List-Subscribe: List-Archive: List-Post: List-Help: , 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 To: cygwin-apps AT cygwin DOT com Subject: Re: Keeping base, adding standard. Message-ID: <20020323060028.GA3348@redhat.com> Reply-To: cygwin-apps AT cygwin DOT com Mail-Followup-To: cygwin-apps AT cygwin DOT com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23.1i 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 things. 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. cgf