Mail Archives: cygwin-apps/2001/12/17/14:22:29
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
- Raw text -