Gentoo Archives: gentoo-dev

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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

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