Gentoo Archives: gentoo-dev

From: hasufell <hasufell@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides.
Date: Tue, 05 Jun 2012 12:31:05
Message-Id: 4FCDFADB.6090708@gentoo.org
In Reply to: Re: [gentoo-dev] [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides. by "Michał Górny"
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA1
3
4 >
5
6 > But could there be a case where fixing a build in the engine
7 > wouldn't require data being rereleased? Or having the tag pointing
8 > to the same commit it was pointing to previously?
9 >
10 > If upstream splits a package, and supports building/installing the
11 > two parts separately, we should do that as well.
12
13 No. That is convenience for the minetest developer to have those
14 split. There is not much sense to have it split unless you don't want
15 to use the game and it adds further maintenance time for me.
16
17 It is also crucial to have the same version for both repos, cause
18 mixing engine and game-versions may lead to unexpected behavior. But I
19 don't understand how that discussion is related to this topic.
20
21 >
22 > Does splitting the package benefit user? Gentoo has a long history
23 > of overusing USE flags out of laziness. If upstream explicitly
24 > allows building GTK+ part separately of core, we shouldn't merge
25 > that. We should rather be grateful they don't force us to end up
26 > like Fedora, splitting build tree into smaller packages.
27
28 Please have a look at those packages. It makes perfectly sense to
29 introduce a gtk useflag since they use almost the same perl
30 core-script, but it is not necessary.
31 This way I could conditionally install one version, since upstream
32 syncs this core-script between both variants.
33
34 >
35 > As I see the purpose of vcs-snapshot, it is more likely to be used
36 > in various overlays than in the gx86 tree. I don't believe you are
37 > able to fix *all* the occurrences.
38
39 Alright, that may be true. I will have a look if it's possible to
40 enhance this without causing breakage for existing packages.
41
42 We may as well have this discussion later. As for your current
43 suggestion you have my ++
44 However the description stuff inside the eclass might need adjustment too.
45 -----BEGIN PGP SIGNATURE-----
46 Version: GnuPG v2.0.19 (GNU/Linux)
47 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
48
49 iQEcBAEBAgAGBQJPzfrbAAoJEFpvPKfnPDWzgAQH/1PdtK2RVRy8M43hW/s2v+wh
50 hRT3FZdEyFYmjMcOyNbzWlu0Y4DnFfbJIYbVWKrr892NQB4o+o4kaEpHmB0wX/gI
51 Igu1ojGkntpfH9NFFXvZDTSwcCLV6ZAtnfq/CAfl5Y100Xdnz64D3nhvse/kXUFH
52 6KYwUX7llsGGKFT3BU/w8i+PXecHDKNrqY48H3XnzTYxk92D6jMkXcSk6PXqVYJQ
53 C1Ug5mjWSBd4ZIPl3CIxxkVXQMFYOgRmM38/vztMNaAt7ypXVJL1sdmR4VHr7k2S
54 WnBtw+eKwTuYJb/M/vHfANhudIOtNOfvCQPZA9nmU5qKpgJ2/iyZAYnhN/WfAd4=
55 =965z
56 -----END PGP SIGNATURE-----