Post details: Using Blockers to Adjust Merge Order and Avoid Conflicts

19 August, 2007

Permalink 00:06 UTC, by Zac MEDICO Email , 355 words, 3047 views   English (US)
Categories: Gentoo

Using Blockers to Adjust Merge Order and Avoid Conflicts

Gentoo users often think of blockers [1] negatively since it can be annoying to resolve them manually. Since portage-2.1.2, in some cases emerge can automatically adjust merge order to resolve blockers so that the user doesn't have to know about them.

Often, the conflict is caused by 2 packages installing files in the same location. A fairly common case that can be resolved automatically is when a file moves from one package to another between versions. For example, udev versions between 111 and 113 install the file /etc/udev.d/rules.d/64-device-mapper.rules which is also installed by device-mapper-1.02.19-r1. If a user upgrades to device-mapper-1.02.19-r1 while a version of udev between 111 and 113 is still installed, a file collision will occur [2]. It's best to avoid file collisions since the version that one package installs is not necessarily compatible with the version that another package installs. The collision can be avoided automatically by adding RDEPEND="!~sys-fs/udev-111 !~sys-fs/udev-112 !~sys-fs/udev-113" to the device-mapper-1.02.19-r1 ebuild. This causes the merge order to be adjusted so that udev is upgraded before device-mapper. The colliding file is uninstalled during the udev upgrade and then reinstalled during the device-mapper upgrade.

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild U ] sys-fs/udev-114 [113]
[ebuild U ] sys-fs/device-mapper-1.02.19-r1 [1.02.19]

File collisions aren't the only situation where blockers can be useful to adjust merge order. For example, some stage tarballs contain a minimal version of perl than has the "build" USE flag enabled. Some packages such as Test-Harness that depend on perl can not be built until perl is rebuilt without that flag. This type of conflict can be represented in the perl ebuild with RDEPEND="build? ( !perl-core/Test-Harness )". The merge order will be automatically adjusted so that perl is rebuilt before Test-Harness is installed.

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild R ] dev-lang/perl-5.8.8-r2 USE="-build*"
[ebuild N ] perl-core/Test-Harness-2.64

[1] A blocker is a type of ebuild dependency that represents a conflict between 2 packages.
[2] File collisions can be detected by adding "collision-protect" to the FEATURES variable in /etc/make.conf.

Trackback address for this post:

http://planet.gentoo.org/developers/htsrv/trackback.php/1384

Comments, Trackbacks:

Comment from: Joshua Nichols [Visitor] Email · http://technicalpickles.com
This is very cool stuff Zack.

This will go a long way to making some upgrade paths much saner. Boy, if we had this a year ago, the new Java system upgrade would have been much smoother :) Hopefully this tactic can get more widely propogated / documented so developers will take advantage of it in the future.

Keep up the good work!
PermalinkPermalink 20 August, 2007 @ 03:50
Comment from: Daniel Drake [Visitor]
That's fantastic. I am often confused by blockers myself, it's great to see portage figuring out how to avoid them. Thanks!
PermalinkPermalink 21 August, 2007 @ 23:11
Comment from: Donnie Berkholz [Visitor] Email · http://spyderous.livejournal.com/
It's a good idea, but I can't help but feel the information is going in the wrong place. Perl shouldn't need to know every package that's incompatible with it; those packages should be the ones saying they don't work with perl.
PermalinkPermalink 22 August, 2007 @ 05:14
Comment from: Zac MEDICO [Member] Email · http://dev.gentoo.org/~zmedico/
The relationship between perl and Test-Harness could be represented as a USE based dependency inside the Test-Harness ebuild, like DEPEND="dev-lang/perl[-build]". Anyway, the blocker approach serves as a potentially useful illustration.
PermalinkPermalink 22 August, 2007 @ 06:21
Comment from: Brad C [Visitor] Email
Hey, thanks a lot for this great, helpful post. Blockers are definitely confusing at times, so this is a great help.
PermalinkPermalink 13 January, 2008 @ 05:34

Leave a comment:

Your email address will not be displayed on this site.
Your URL will be displayed.

Allowed XHTML tags: <p, ul, ol, li, dl, dt, dd, address, blockquote, ins, del, span, bdo, br, em, strong, dfn, code, samp, kdb, var, cite, abbr, acronym, q, sub, sup, tt, i, b, big, small>
(Line breaks become <br />)
(Set cookies for name, email and url)
(Allow users to contact you through a message form (your email will NOT be displayed.))

Zack Medico

July 2008
Mon Tue Wed Thu Fri Sat Sun
<< <     
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

Search

Categories

Misc

XML Feeds

What is RSS?

Who's Online?

  • Guest Users: 90

powered by
b2evolution