On Wed, 2014-07-23 at 01:13 +0200, Tom Wijsman wrote: > On Mon, 21 Jul 2014 21:34:10 -0400 > Alexandre Rostovtsev <tetrom...@gentoo.org> wrote: > > Why not adapt the updates mechanism for modifying rdepends? Perhaps > > something like > > > > rdepends-add foo-bar/blah-3.14 "wombat? ( >=dev-libs/wombat-1.0 )" > > > > This would give the package manager all the benefits of static dep > > resolution while allowing us to dynamically make simple changes (like > > adding a missing dependency to an ebuild) without forcing users to > > rebuild the package. > > Thinking this through: > > 1) What about rdepends-change and rdepends-del? If you only support > addition; you get the same problem as with things like pkgmove, > changing and/or removing it could become somewhat problematic.
rdepends-add is easy to implement: just append a string to RDEPENDS and reparse it. Deletion is trickier. It's clear what it means to delete an atom from a flat list of atoms. But specifying what it means to delete a part of a complex expression (conditionals, disjunctions) requires some careful thought. > 2) This needs two commits every time you want to do this; one commit > for the updates/, another to keep the ebuild recent for (rev)bumps. Yes, but that's just more incentive to migrate to git :) > 3) It'll be a lot of fun to attempt to support this in Repoman. Ideally, repoman would suggest what you should add to updates/ when it detects that you are committing a change to an existing ebuild. > 4) How do we clean up these entries? Doesn't this info grow fast? The point is to *not* clean up these entries for months/years. I want to address the situation where a users installs from an ebuild with wrong dependencies, the next day the ebuild gets its dependencies fixed in cvs, two weeks later the ebuild gets deleted from cvs, and only then the user resyncs. With our current dynamic depends, as well as with the proposed "minor revisions" mechanism, the user will still have a broken vdb. I want to make sure the user's vdb gets updated even when the ebuild in question is gone from portage. > 5) The first paramater: Should that point to a single ebuild? Should > that support ranges? Just like everything else in profiles/, so for now, that means a single dependency specification. If you want version ranges, they should be allowed in package.mask too :)
signature.asc
Description: This is a digitally signed message part
