Ottavio Caruso <ottavio2006-usenet2012%yahoo.com@localhost> writes: > Imagine this scenario: I have package v 1.2 installed from the latest > stable repos. A new version 1.4 is available in current with more > functionalities. Package 1.4 comes with a baggage of various version > bumps, therefore it requests that many dependencies be removed and > upgraded. > > My goal is to create the least possible builds of needed dependencies > and then manually install them with either pkgin or pkg_add. Basically mixing pkgsrc branches (stable and head) may or may not work, but often you can do it. "version bump" is a confusing term. There are two separate issues: changing the upstream version of a package (1.2 to 1.4, as you mention) PKGREVISION++, where we increase the nbN number on purpose to force a version mismatch for a depending packages when there is an ABI change in a package. This "recursive revision bump" is aimed at users of binary packages. It's certainly true that upstream package version changes tend to go together, where 1.4 of package A will now need 3.1 of B, whereas B was at 3.0 in pkgsrc, so when someone commits the update of 1.4 they will first have to update B to 3.1. Assuming you aren't going to set up bulk builds (a reasonable call; it's not trivial), there are basically two approaches, fraught with different perils. Assume you want the new version of pkgsrc/foo/bar. 1. in foo/bar, "cvs up -A", and try to build it. if it works, make replace. Then pkg_rolling-replace -v to rebuild anything that depends on foo/bar. 2. update all of pkgsrc with cvs up -A in /usr/pkgsrc. in foo/bar, make package, and every time it fails because it requires a new version of a dependendency, go to that dependencies directory and do "make replace". When you're done, do pkg_rolling-replace -v (*not* -u) to rebuild anything that depends on a replaced package. Option 1 is pretty safe, but may or may not work. Option 2 is likely to get you into trouble. The real question is whether foo/bar can be built against the versions of dependencies that are in 2014Q2. It's pretty likely that it can, but of course it might not be doable. In option 2, that's not the question - it is coded as depending on some package via a buildlink3 file, and that may require the version in head. In option 1, you'll include the 2014Q2 version of the bl3 file, which will be happy with the 2014Q2 version. It's possible that the foo/bar Makefile will explicitly require some newer version of a dependency. In that case you can essentially execute option 1 for that dependency, but refrain from updating the entire cvs tree to head.
Attachment:
pgpCf082cWtqv.pgp
Description: PGP signature