Am 20.07.10 16:42, schrieb Miguel Enrique Cobá Martínez: > El mar, 20-07-2010 a las 10:17 +0200, Mariano Martinez Peck escribió: >> Hi Miguel. I understand your problem, and we are working on that with >> Dale and Stef. Having repositories for a specific Pharo version and so >> on. But we are just starting.... >> >> By the moment, you can use what Sean told you, or, just update the >> configuration, but in a new version. I mean....if you had the version >> 2.3.4 that was released and working in pharo 1.0, then don't touch it, >> create a new one, say, 2.4 and that works in 1.1. Of course this is >> not the perfect solution, but for the moment. But one thing for sure: >> do not update the SAME version that was working for 1.0. >> Magma should continue working in 1.0 using the same metacello version. > > Exactly. I will do it this night. > > BTW. What will be the solution, copying directories (debian does this > too. They copy the repository contents and then diverge from them. The > previous repository only receives bug fixes) but the solution of Dale, > as I understand it uses tags to identify what version is running on and > then load only the packages for that version. This solution is a third > alternative. So by now we have: > > - Copy repositories of configurations for each new release > - Use version attributes for conditionally loading packages in version > methods. > - Use tags to mark the pharo release a given version method applies. > Then metacello searches for the version method with the highest number > that is tagged with the release number of the image (got from > SystemVersion) > > Cheers Hi,
Wouldn't it be good to also ask the maintainer of the offending packages to change the assignments such that Pharo will be happy without changing the preference? Regards, Andreas _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
