Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC about another *DEPEND variable
Date: Thu, 21 Sep 2006 12:03:35
Message-Id: 20060921115916.GB30105@seldon
In Reply to: Re: [gentoo-dev] RFC about another *DEPEND variable by Luca Barbato
1 On Thu, Sep 21, 2006 at 01:38:59PM +0200, Luca Barbato wrote:
2 > Alin Nastac wrote:
3 > >I reckon this could be solved by yet another *DEPEND variable. The only
4 > >atoms accepted by this variable would be "CATEGORY/PN". Every time when
5 > >a package gets updated from PV1 to PV2 (distinct versions, revisions
6 > >will not count), portage will automatically re-emerge those packages
7 > >that depend on it.
8 > >
9 > >Thoughts?
10 > >
11 >
12 > It would require revdep resolution on emerge... how painful would be?
13
14 Off the top of my head, adding revdeps (period) for unmerge
15 functionality (fex) is the harder part; slipping something of this
16 sort in is just a logic tweak.
17
18 The problem with this proposal however is that it's attempting
19 automatic revdep based off of version; _any_ non-rev version bump is
20 way too rebuild happy.
21
22 Proposal I was pushing a while back was addition of a metadata key;
23 it's not exactly .so version, but pretty close- a _manually_
24 maintained counter var in the ebuild that represents the abi
25 compatibility for that packages versions.
26
27 Example would be openssl-0.9.7, you stick BINCOMPAT=0.9.7 in it,
28 in openssl-0.9.8, you stick BINCOMPAT=0.9.8 in it, for a replace op
29 the resolver sees that it's breaking compatibility and knows to
30 rebuild any revdeps.
31
32 Why have the explicit var? Because 0.9.7a through 0.9.7c may all be
33 compatible, but 0.9.7d isn't. If you force an automatic algo that
34 tries to (effectively) guess, you get a lot of rebuilds through a,b,c,
35 end result being folks likely update less because it becomes a bigger
36 pain in the ass.
37
38 There is one flaw with this though; packages can provide both
39 libraries _and_ binaries. Our dependencies don't represent whether
40 the dep is actual linkage, or just commandline consuming, so (using
41 the openssl example) any package that invokes openssl via the
42 commandline to do a few simple chksum ops gets rebuilt, despite the
43 fact it wasn't affected by linkage change ups.
44
45 So... short version, at least what jstubbs/marius/myself hashed out in
46 irc a long while back, need binding dependencies and actual tracking
47 of the lib breakage in the metadata.
48
49 Alternative to shoving an extra key in would be extending slot rules,
50 but that can be somewhat ugly.
51
52 My 2 cents, for what its worth.
53 ~harring

Replies

Subject Author
Re: [gentoo-dev] RFC about another *DEPEND variable Mike Frysinger <vapier@g.o>
Re: [gentoo-dev] RFC about another *DEPEND variable Alin Nastac <mrness@g.o>