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