This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Keeping base, adding standard.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]