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: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Message-ID: <3CD36645.1060703@ece.gatech.edu>
Date: Sat, 04 May 2002 00:40:37 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: cygwin-apps AT cygwin DOT com
Subject: Re: new cygwin package: cgoban
References: <3CCED93D DOT 5081E0A5 AT freeler DOT nl> <20020503114633 DOT A22456 AT cygbert DOT vinschen DOT de> <20020503153327 DOT GF17660 AT redhat DOT com> <3CD2DF24 DOT 2010702 AT ece DOT gatech DOT edu> <20020504033515 DOT GC32261 AT redhat DOT com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Be sure to read the p.s. ...

Christopher Faylor wrote:

> On Fri, May 03, 2002 at 03:04:04PM -0400, Charles Wilson wrote:
> 
>>Similarly, I don't like the restriction that all 'X'-based packages go 
>>under XFree86/ on sourceware.  We don't put inetutils underneath 
>>ncurses/.  We don't put openssh under openssl/.
>>
> 
> I wasn't really asking for debate.  You can feel free not to like it
> but that is the way I would like to see things organized.


Sorry, Chris, but it's my turn to get pissy.

Why?  You have never stated, not one time that I've seen, WHY you want 
to put all X-related stuff under a single tree.  As long as they are 
under release/, they're still going to show up in setup no matter where 
they are located, so setup's behavior can't have anything to do with it. 
  If it's a "cleanliness" issue (don't clutter the main release/ dir 
with all that "X junk") -- fine, SAY that.  At least it's a reason -- 
and a slightly better one than "because I said so".  And I've already 
heard the one about "because we're mean".

Further, if one accepts that there should be one tree for all X 
**clients**, you've never stated WHY that single tree must be the same 
one used by the XFree86 packages. They aren't PART of XFree86.  They 
just USE XFree86.  It's not that I merely 'don't like it' -- I think 
this second part is irredeemably dumb.  WHAT am I missing?  Please tell 
me; you normally don't make executive assertions without a reason, you 
don't normally do dumb things; yet you seem to be doing so now...which 
makes me think I am somehow missing the "obvious" reasoning behind your 
assertion.

This just makes zero sense to me:

release/package/
release/package/
release/XFree86/
release/XFree86/xfree86-base/
release/XFree86/xfree86-fonts/
release/XFree86/xfree86-.../
release/XFree86/i-happen-to-use-x-package1/
release/XFree86/i-happen-to-use-x-package2/
release/XFree86/i-happen-to-use-x-package3/
release/XFree86/i-happen-to-use-x-package4/
release/XFree86/i-happen-to-use-x-package5/
release/XFree86/i-happen-to-use-x-package6/
release/XFree86/i-happen-to-use-x-package7/
release/XFree86/i-happen-to-use-x-package8/

This makes (some) sense, from a 'keep-release/-clutter-to-a-minimum' 
perspective ...

release/package/
release/package/
release/XFree86/
release/XFree86/xfree86-base/
release/XFree86/xfree86-fonts/
release/XFree86/xfree86-.../
release/Xclients/i-happen-to-use-x-package1/
release/Xclients/i-happen-to-use-x-package2/
release/Xclients/i-happen-to-use-x-package3/
release/Xclients/i-happen-to-use-x-package4/
release/Xclients/i-happen-to-use-x-package5/
release/Xclients/i-happen-to-use-x-package6/
release/Xclients/i-happen-to-use-x-package7/
release/Xclients/i-happen-to-use-x-package8/

--Chuck

P.S. wait a minute; I thought of something.  Is this a prelude to "Any 
questions about packages that appear under /XFree86/ should be directed 
to the cygwin-xfree list?"  And you're afraid that splitting out the 
Xclients -- either into /release/ or into /release/Xclients/ -- would 
cloud that issue?