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>
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Message-ID: <3C79380C.8090002@ece.gatech.edu>
Date: Sun, 24 Feb 2002 13:59:24 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; 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: pkgconfig
References: <FC169E059D1A0442A04C40F86D9BA760014ADE AT itdomain003 DOT itdomain DOT net DOT au> <3C774EAA DOT 9000204 AT ece DOT gatech DOT edu> <010f01c1bd1f$7b925cf0$0200a8c0 AT lifelesswks> <20020224162120 DOT GB17909 AT redhat DOT com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Christopher Faylor wrote:

> On Sun, Feb 24, 2002 at 09:39:04PM +1100, Robert Collins wrote:
> 
>>>Well, yeah, me too -- but setup got confused, according to some users,
>>>the last time we tried moving packages around (ncurses).  Lets verify
>>>that the soon-to-be-released setup can handle moving ONE package
>>>(gettext?) before advocating a wholesale rearrangement.  (AND give
>>>everybody out there some time to switch from the old 'stable' setup to
>>>the new 2.194.2.x one).
>>>
>>What, change control?  Ha!.  Seriously though, setup will handle it
>>fine, as package comparison is directory tree context free.  upset
>>might be a little though.
>>
> 
> upset will handle it.  It doesn't care where stuff is stored.  It makes
> no distinction between contrib and latest.


Okay, that's good.  IIRC, the problems that cropped up before involved 
the fact that /etc/installed.db listed installed packages WITH their 
package path, and package comparison *included* the path:

contrib/zip/zip-2.3-4.tar.bz2 <size>
latest/bzip2/bzip2-1.0.1-4.tar.bz2 <size>
contrib/ncurses/ncurses-5.2-4.tar.bz2 <size>

And then, when setup tried to compare THAT with the new setup.ini which 
specified (for instance)

latest/ncurses/ncurses-5.2-5.ta4.bz2 <size>

setup failed to recognize that those two packages were really just 
different versions of the same pacakge -- it didn't uninstall the old 
one, but DID install the new one, and now installed.db listed TWO packages:

contrib/ncurses/ncurses-5.2-4.tar.bz2
latest/ncurses/ncurses-5.2-5.tar.bz2

or some such.  And then, MUCH wackiness ensued -- because some parts of 
the code did pathless comparisons, and other parts did not.  Since 
Robert asserts that package comparisons are now done SOLELY on package 
name and NOT path, this 'wackiness' won't happen.  Good enough for me.

So, the only objections to rearranging the package structure is:

1) bandwidth to the mirrors
2) conflicts between 'fast' mirrors and 'slow' mirrors
3) the multi-repository code when two repositories have the same package 
on different local paths.
4) repository storage: I've noticed that many mirrors only add new 
tarballs -- they never remove the old tarballs even when sourceware HAS 
removed them.  So, these repositories will have redundant copies of the 
relocated packages -- one in the old location and one in the new.  If 
setup.ini doesn't refer to the outofdate locations, then this shouldn't 
cause US problems; the folks who pay for the disk drives on the mirrors 
may worry tho...

If these are not serious worries, then:

1) I'll wait until the new setup is out for a few days
2) I'll move the gettext package from contrib/ to latest/

If this is successful, then we will have *proven* -- as opposed to the 
armchair analysis that we've been doing in this thread -- that there is 
no problem with relocating packages in the repository.  THEN, and *only* 
then, Chris could begin to rearrange things on sourceware -- if he wants 
to do so.

--Chuck