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
