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: <3C1E4616.5090408@ece.gatech.edu>
Date: Mon, 17 Dec 2001 14:23:02 -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: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
CC: cygwin-apps AT cygwin DOT com
Subject: Re: Restructuring gettext
References: <FC169E059D1A0442A04C40F86D9BA7606291 AT itdomain003 DOT itdomain DOT net DOT au>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Robert Collins wrote:

fer not to complicate the "libfooX" package by 
>>starting down the 
>>path where "libfoo1" contains both cygfoo-1.dll and cygfoo.dll.  I'd 
>>rather insure that libfooX contains only cygfoo-X.dll -- and put 
>>cygfoo.dll into libfoo0 or just plain libfoo.
>>
> 
> I was approaching this from two angles.
> 1) On unix you'd promably symlink or hardlink to provide this. In point
> of fact all you need is a tarball with a hardlink to the old library
> name, and cygwin will work just fine.


Well, yeah -- in a perfect world, we would've been using libfooX package 
names for shared libs from "the beginning" and this issue of 'what do we 
do when splitting a monolithic package into pieces' would never arise.

You're arguing that BOTH DLL's should have the same "binary compatbility 
index" -- but they don't.  My bad.  Since they (erroneously) don't have 
the same bincompind, they should be in separate packages -- otherwise, 
even after cygintl.dll is no longer required by any package, it will 
still be installed (by libintl1 package) as long as cygintl-1.dll is 
needed...


> 2) You're adding a package that can never get pulled in by anyone else -
> because there is no -dev for it - and that is binary compatible with the
> current package. Doesn't make sense to me, but that's just my view :} -
> do as makes sense to you.


I'm really not worried about expanding the package namespace; I think 
it's more important to establish that 'libfooX will contain the DLLs 
with compat index X and nothing else' as a precedent, than to conserve 
namespaces...


>>I don't know how to deal with the problem above -- which 
>>occurs if the 
>>package being split (ncurses, readline, gettext) follows rather than 
>>precedes 'l'ibXXXX in the alphabet...but we can deal with 
>>that when/as 
>>it occurs.  (Perhaps upgrades of currently installed packages should 
>>ALWAYS precede installation of new packages?)
>>
> 
> See my wishlist item regarding sorting of activities. 
> 
> upgrades of current packages first is one sort parameter. Dependency
> ordered installs is another. File conflict detection and atomic installs
> is a related and needed issue. So the logic goes something like:
> 
> build two ordered graphs of packages (where two nodes are joined if node
> A is required by node B for the first one, and conflicts with for the
> second).
> 
> Then sort the packages.
> a) if two packages are not related in the graph (no path joins them in
> either direction) then they are ordered by installed status - installed
> packages first.
> b) packages that can be reached from other packages come before those
> packages. (ie A depends on B, A gets installed first, and if D 1.0
> conflicts with C < 1.2, and C1.1 is installed, then D is after C).
> c) packages that are mutually reachable (or co-dependent) have the
> required version number decide. i.e. if bash needs profile-setting > 2
> (and 2 is installed) , and profile-setting needs bash, then
> profile-setting would be done first, as otherwise the bash install would
> potentially fail. 
> 
> When installing, if a file conflict arises, (ie the libncurses package
> conflict with older ncurses) and the conflicts clause doesn't explicitly
> mark this, then the package being installed is rolled back, and the
> install skips over all packages that can reach it in the dependency
> graph. 
> After installing everything else, the failed package is tried again. If
> a conflict still exists, then the dependenct packages that are satisfied
> by the currently installed version of the failing package are installed.
> if the conflicting package can reach the failing package in the install
> graph (regardless of whether the conflicting package depends on the
> failing package) then it is tried as soon as any other dependencies are
> met.
> 
> Thoughts?


</me waits for head to stop spinning>
...
<okay>

Sounds like it would work; I think the stuff preceeding the final two 
paragraphs is more important initially, and can be implemented before 
and independent of the latter stuff...and tested/released before work on 
the latter stuff is begun.

--Chuck