Zack Medico - Latest comments on Handling File Collisions Between Blocking Packages http://blogs.gentoo.org/zmedico?disp=comments en-US http://backend.userland.com/rss 60 In response to: Handling File Collisions Between Blocking Packages Thu, 05 Jun 2008 20:52:01 +0000 Zac MEDICO [Member] c19866@http://blogs.gentoo.org/ You can unmask portage-2.1.5* like this:<br /> <br /> <code>echo "=sys-apps/portage-2.1.5*" >> /etc/portage/package.keywords<br /> </code><br /> <br /> See the <a href="http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#book_part3_chap3__chap2_sect2" rel="nofollow">Test Particular Versions</a> part of the Handbook for more information about keywords.<br /> <br /> Portage 2.1.5.4 is probably good enough to be marked stable but it needs a couple more weeks of testing first.
echo "=sys-apps/portage-2.1.5*" >> /etc/portage/package.keywords


See the Test Particular Versions part of the Handbook for more information about keywords.

Portage 2.1.5.4 is probably good enough to be marked stable but it needs a couple more weeks of testing first.]]> http://blogs.gentoo.org/zmedico/2008/05/09/blocking_package_file_collisions#c19866 In response to: Handling File Collisions Between Blocking Packages Thu, 05 Jun 2008 20:09:52 +0000 Arthur Torrey [Visitor] c19865@http://blogs.gentoo.org/ I'm confused... <br /> <br /> Just saw this referenced in GMN, looks fantastic, but after a sync, emerge -s only offers portage 2.1.4.4 as listed... I have that version installed, and it doesn't do blocker removal.<br /> <br /> When/where do we get Portage 2.1.5?<br /> <br /> ART
Just saw this referenced in GMN, looks fantastic, but after a sync, emerge -s only offers portage 2.1.4.4 as listed... I have that version installed, and it doesn't do blocker removal.

When/where do we get Portage 2.1.5?

ART]]> http://blogs.gentoo.org/zmedico/2008/05/09/blocking_package_file_collisions#c19865 In response to: Handling File Collisions Between Blocking Packages Wed, 04 Jun 2008 13:09:58 +0000 Thomas [Visitor] c19864@http://blogs.gentoo.org/ Just came here via the GMN and that's really great! I recently had my first look into portage's source code (after years of using it) and it's great to see the work you do - and some long wanted features materialize.<br /> <br /> I tried both pkgcore and paludis, and while they are nice in their own ways, I just feel more comfortable with portage on production machines, and I'm very glad it's getting some love, too. Keep up the good work!
I tried both pkgcore and paludis, and while they are nice in their own ways, I just feel more comfortable with portage on production machines, and I'm very glad it's getting some love, too. Keep up the good work!]]> http://blogs.gentoo.org/zmedico/2008/05/09/blocking_package_file_collisions#c19864 In response to: Handling File Collisions Between Blocking Packages Tue, 13 May 2008 04:55:43 +0000 Zac MEDICO [Member] c19844@http://blogs.gentoo.org/ <p>Indeed, some cases may exist such that temporary simultaneous installation of blocking packages will cause some sort of problem. However, the solver will only choose this type of solution for blockers that it is not able to satisfy in any other way, such as by <a href="http://planet.gentoo.org/developers/zmedico/2007/08/19/using_blockers_to_adjust_merge_order" rel="nofollow">simple adjustment of merge order</a>. In addition, it will not choose this type of solution if a blocking package will overwrite files belonging to either of the following types of packages: </p> <ul> <li>Those that belong to the system set.</li> <li>Required runtime dependencies of <a href="http://packages.gentoo.org/package/sys-apps/portage" rel="nofollow">portage</a> itself.</li> </ul> <p>The above constraints serve to limit the probability that the chosen solution will cause some sort of problem. If testing shows that these constraints are not sufficient to separate good solutions from bad solutions in a significant number of cases, then we will have to devise additional constraints if possible, or else extend blocker syntax to indicate which type of solution is appropriate for a given blocker relationship.</p> Indeed, some cases may exist such that temporary simultaneous installation of blocking packages will cause some sort of problem. However, the solver will only choose this type of solution for blockers that it is not able to satisfy in any other way, such as by simple adjustment of merge order. In addition, it will not choose this type of solution if a blocking package will overwrite files belonging to either of the following types of packages:

  • Those that belong to the system set.
  • Required runtime dependencies of portage itself.

The above constraints serve to limit the probability that the chosen solution will cause some sort of problem. If testing shows that these constraints are not sufficient to separate good solutions from bad solutions in a significant number of cases, then we will have to devise additional constraints if possible, or else extend blocker syntax to indicate which type of solution is appropriate for a given blocker relationship.

]]> http://blogs.gentoo.org/zmedico/2008/05/09/blocking_package_file_collisions#c19844 In response to: Handling File Collisions Between Blocking Packages Tue, 13 May 2008 02:14:53 +0000 kai [Visitor] c19843@http://blogs.gentoo.org/ It seems like the process, of installing the new package then removing the old one, should still work. Are there some situations where that is just a bad assumption? <br /> <br /> And thanks for looking at that, definitely an itchy spot there.
And thanks for looking at that, definitely an itchy spot there.]]> http://blogs.gentoo.org/zmedico/2008/05/09/blocking_package_file_collisions#c19843 In response to: Handling File Collisions Between Blocking Packages Sat, 10 May 2008 09:21:53 +0000 igli [Visitor] c19841@http://blogs.gentoo.org/ Heh, I remember some dev mentioning that as a feature he'd really like; in place upgrade for blockers in exactly the manner you describe: only unmerge old when new is about to be installed (ie after successful compile.) Nice work.<br /> ]]> http://blogs.gentoo.org/zmedico/2008/05/09/blocking_package_file_collisions#c19841 In response to: Handling File Collisions Between Blocking Packages Sat, 10 May 2008 05:39:48 +0000 Zac MEDICO [Member] c19840@http://blogs.gentoo.org/ <p>In some cases, the smoothest way to perform an upgrade is to merge the new package files into place and then remove any files that belong to the old package (only the ones that do no overlap with the new package). That's how <a href="http://packages.gentoo.org/package/sys-apps/portage" rel="nofollow">portage</a> has always done it for normal upgrades within a package slot.</p> <p>Now, in some cases, we have similar behavior with packages that block each other, so the "smooth upgrade" process is no longer confined to a single package slot. The process can be spread over multiple packages that block each other.</p> In some cases, the smoothest way to perform an upgrade is to merge the new package files into place and then remove any files that belong to the old package (only the ones that do no overlap with the new package). That's how portage has always done it for normal upgrades within a package slot.

Now, in some cases, we have similar behavior with packages that block each other, so the "smooth upgrade" process is no longer confined to a single package slot. The process can be spread over multiple packages that block each other.

]]> http://blogs.gentoo.org/zmedico/2008/05/09/blocking_package_file_collisions#c19840 In response to: Handling File Collisions Between Blocking Packages Sat, 10 May 2008 04:53:17 +0000 igli [Visitor] c19839@http://blogs.gentoo.org/ Hmm ok; seems a bit unnecessary if the new pkg is going to be installing the same file, or is this something to do with having them both on system during upgrade?<br /> <br /> Well done for getting the automatic uninstall, man, and thanks from someone who'll save a lot of time as a result.
Well done for getting the automatic uninstall, man, and thanks from someone who'll save a lot of time as a result.]]> http://blogs.gentoo.org/zmedico/2008/05/09/blocking_package_file_collisions#c19839