Mail Archives: cygwin-apps/2001/12/16/23:37:39
> -----Original Message-----
> From: Charles Wilson [mailto:cwilson AT ece DOT gatech DOT edu]
> > Right. But the one package could provide the same .dll
> twice (until all
> > dependent packages are rebuilt).
> I'd prefer 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.
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.
> setup automatically determined that I needed to:
> a) update gettext from 0.10.38-2 to 0.10.40-1
> b) install the "new" libintl0-0.10.38-3 package
> c) install the new libintl1-0.10.40-1 package
>
> Since "g"ettext comes before "l"ibintl0, the
> uninstall/reinstall occured
> in the proper order, and I still had a working system. Unlike
> ncurses,
> alphabetization works for us here -- it would be bad if libintl0 was
> installed (replacing cygintl.dll with the "new" version), and THEN
> gettext was uninstalled (removing cygintl.dll) followed by installing
> the new gettext (which contains no cygintl.dll).
>
> 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?
Rob
- Raw text -