At 14:16 Uhr -0500 11.02.2002, David R. Morrison wrote: >Here's a problem. There are two packages, A and B. Let's say the >current versions are A.1 and B.1. At the moment, B depends on A. > >We need to upgrade these packages. After the upgrade, B.2 will >BuildDepend on A.2, but no longer Depend on it. > >After upgrading A to A.2, there is a 50-50 chance that B.1 will not >function correctly. (This is why we are upgrading, to fix this for the >future! At the moment, the way that B was compiled depends on whether some >other package was installed at the time that B was built, and this is not >good.) So we need to make sure that B gets upgraded to B.2 also. > >I see two ways to do it, neither one perfect. Maybe somebody can think >of a better way? > >Method 1: > package A.2 > Conflicts: B (<< 2) > package B.2 > BuildDepends: A (>= 2) > >Method 2: > package A.2 > no requirements > package B.2 > BuildDepends: A (>= 2) > >In the case of method 1, it is impossible to upgrade without removing B >and later reinstalling it. (If B.1 is installed and you try to build B.2, >it wants to install A.2 first but A.2 conflicts with B.1). It would be >nice if the user didn't have to do this. However, at the end of the >process everything will work properly. > >In the case of method 2, the user might happen to upgrade A without >upgrading B. There is a 50-50 chance that things will break; if they are >broken, the user can be told to upgrade B also. Or, if the user decides to >upgrade B first, everything is fine. > >Which one is better? Or is there a third method I haven't thought of?
I don't see a third method. I'd prefer method 2 for now. While it can end it "broken" packages, this problem then can easily be worked around. OTOH, having to temporarily deinstall package may not be really feasible, e.g. when 20 installed packages depend on that package... Max -- ----------------------------------------------- Max Horn Software Developer email: <mailto:[EMAIL PROTECTED]> phone: (+49) 6151-494890 _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
