Gentoo Archives: gentoo-dev

From: Ian Stakenvicius <axs@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] don't rely on dynamic deps
Date: Fri, 25 Jul 2014 17:36:33
Message-Id: 53D2958D.2000203@gentoo.org
In Reply to: Re: Re: [gentoo-dev] don't rely on dynamic deps by "Andreas K. Huettel"
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA256
3
4 On 25/07/14 01:15 PM, Andreas K. Huettel wrote:
5 >
6 >>> Maybe this could be solved by having two kinds of revisions: -
7 >>> One would rebuild all as usually (for example, -r1...) - The
8 >>> other one would only regenerate VDB and wouldn't change the
9 >>> installed files (for example, -r1.1)
10 >>>
11 >>> But I am not sure if it could be viable from a "technical"
12 >>> point of view :(
13 >>
14 >> I'm afraid it couldn't. The major problem is not knowing *when*
15 >> to migrate metadata, portage usually gets that right. The problem
16 >> is in getting the correct output which is often near to
17 >> impossible.
18 >
19 > I think we'd appreciate some more information here:
20 >
21 > * What exactly is the metadata that we're talking about? * How much
22 > of it can be generated by sourcing the ebuild, without running
23 > phases? * When does that exactly break? Example?
24 >
25
26 It may help this overall discussion to step back even further here:
27
28 * What do we want to accomplish, exactly?
29
30 - allow portage to emerge updated packages without rebuilding them
31 (ie running src_* and pkg_*inst phases), when it can be determined
32 from metadata changes (or for -rX.Y method perhaps it is assumed
33 - -just- on filename changes) that this is not necessary.
34
35 * What are all of the cases that would validly trigger this
36 dont-bother-to-run-phases shortcut?
37
38 - - addition of missing dependency [1]
39 - - new useflag not enabled by default
40 - - removed useflag that was not previously enabled
41 - - changing of dependency atom(s) -- ie swapping a specific atom to
42 virtual one
43 - - EAPI bump (maybe??)
44 - - .... <-- add more please!
45
46
47 * For each of the above, in what cases is a full rebuild probably
48 necessary anyhow??
49
50 - - dependency atom minimum version is increased, and the in-VDB version
51 of this dep is too old (??)
52 - - new dependency atom is missing from VDB (??)
53 - - EAPI bump adds new entries to VDB that need to be calculated from
54 say, merge phase
55 - - ....
56
57
58
59 ..i think from there we can perhaps determine what metadata could be
60 updated and/or needs to be updated to maintain consistency in the
61 dont-rebuild cases we want.
62 -----BEGIN PGP SIGNATURE-----
63 Version: GnuPG v2
64
65 iF4EAREIAAYFAlPSlY0ACgkQ2ugaI38ACPBDHAD+POgCJlbPv9HHwhK4wxd8b2ir
66 ywM71Aemu6SPfCTE2MIBAKATag94jCHLlqwkYN2jrW23tYqTi5ajOwLzoZ/EqHx0
67 =qUpY
68 -----END PGP SIGNATURE-----

Replies

Subject Author
Re: [gentoo-dev] don't rely on dynamic deps Ian Stakenvicius <axs@g.o>
Re: [gentoo-dev] don't rely on dynamic deps Taahir Ahmed <ahmedtd@××××.edu>