Alan Barrett <apb%cequrux.com@localhost> writes: > On Thu, 25 Oct 2012, Aleksej Saushev wrote: >>Consider the following scenario. >>There're two packages installed, A and B, A depends on B. >> >> A -> B >> >>Now, B gets updated but A lags behind, instead B1 is introduced. >> >>When running pkg_rr something triggers update of B. >>It gets rebuilt, replaced, and triggers update of A. >>Now the dependecies look like this: >> >> A -> [B1, yet to build] >> B >> >>If B and B1 conflict, user is in trouble. >>If B is high enough in forest, going back is even harder. > > Yes, that can easily happen. I have most often seen it when a package > is split. For example: > > T1: You install usefulpkg-1.0, which depends on sometool-1.0 > > T2: sometool version 2 is released, and pkgsrc decides to > split it into sometool-base-2.0 and sometool-2.0, > with sometool-2.0 depending on sometool-base-2.0. > > sometool-base-2.0 is marked as conflicting with sometool-1.0. > > pkgsrc changes usefulpkg-1.0nb1 to depend on sometool-base-2.0, > where usefulpkg-1.0 used to depend on sometool-1.0. > > T3: You update your pkgsrc tree, and run pkg_rr. > > pkg_rr wants to upgrade usefulpkg from version 1.0 to 1.0nb1. > > pkg_rr needs to build sometool-base-2.0 as a dependency for > usefulpkg-1.0nb1 I agree with the scenario entirely, but nits: pkg_rr will try to update sometool-1.0 to sometool-2.0 first if not, the building of sometool-base-2.0 will be as a dependsd on usefulpkg-1.0nb1 as a build dependency from make replace > sometool-base-2.0 can't be installed, because it conflicts with > sometool-1.0. > > T4: You figure out what's wrong, manually delete sometool-1.0, > run pkg_rr again, and now it works. Agreed that this is a serious issue with the pkg_rr approach.
Attachment:
pgpptLJGjxULF.pgp
Description: PGP signature