This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
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