From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1SbeFV-0004Bj-RM for garchives@archives.gentoo.org; Mon, 04 Jun 2012 20:51:38 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A43DAE0829; Mon, 4 Jun 2012 20:51:18 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id D4BD5E05F5 for ; Mon, 4 Jun 2012 20:50:27 +0000 (UTC) Received: from [192.168.4.5] (blfd-4d08fca4.pool.mediaWays.net [77.8.252.164]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: hasufell) by smtp.gentoo.org (Postfix) with ESMTPSA id E27CD1B402F for ; Mon, 4 Jun 2012 20:50:26 +0000 (UTC) Message-ID: <4FCD1EE5.30000@gentoo.org> Date: Mon, 04 Jun 2012 22:47:33 +0200 From: hasufell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120502 Thunderbird/10.0.4 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides. References: <1338803954-3814-1-git-send-email-mgorny@gentoo.org> <4FCCC412.6000000@gentoo.org> <20120604175047.1d1ed5a4@pomiocik.lan> <4FCD0BC8.6050608@gentoo.org> <20120604220626.2630937b@pomiocik.lan> In-Reply-To: <20120604220626.2630937b@pomiocik.lan> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: e18d5769-08ad-4bf9-8192-3c34d1def322 X-Archives-Hash: 6121d484b76ffdcb2d168885b49aa46a -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/04/2012 10:06 PM, Micha=C5=82 G=C3=B3rny wrote: > On Mon, 04 Jun 2012 21:26:00 +0200 hasufell > wrote: >=20 >> But minetest in sunrise for example which has two different >> repos, one for the engine, one for the data. It's currently split >> in two, but I guess I will merge those soon. >=20 > Why? Is there a good reason to merge two repos into one ebuild? > Does upstream guarantee that the releases will always be synced? > Does it benefit users? In this case yes. They are released with the exact same tags as you can see in those ebuilds. >=20 >> It would also enable me to use gtk-youtube-viewer and >> youtube-viewer in one ebuild with vcs-snapshot eclass while >> adding a gtk useflag (currently split too). Otherwise I will have >> to fix it on my own again. >=20 > Once again: does it benefit user? Or just does it imply that > starting or stopping to use gtk part requires user to rebuild the > whole thing? Eclasses do not benefit any user. They benefit developers. I would simply do similar stuff on my own in the ebuild instead of using vcs-snapshot eclass then. >=20 >> I find the logic very clear: >>=20 >> SRC=3D"https://my/github/shit -> ${P}.tar.gz" results in >> ${WORKDIR}/${P} and SRC=3D"https://my/github/shit -> >> ${P}-src.tar.gz" results in ${WORKDIR}/${P}-src >=20 > I really don't mind the logic. I'm just aware that it is a little > late to introduce such a destructive change, especially that you > yourself mentioned that it will break existing ebuilds. So? We fix it. >=20 > I will be happy to implement it if you can get more approval for > that change. Or else we should consider jumping with the eclass to > -r1 while it isn't widespread too much. >=20 I don't see the point in bumping it, because it's not widespread. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPzR7lAAoJEFpvPKfnPDWz5W8H/0Je1mE/Vo7X+46TpuZZyi/3 RJaJMYETeQbbhPM6ACIXtHk629fGCz9Oda7J0YG4LMCYTbxU5MNElZSjbV4aThYD MkSoQlSw/RIBuSEaffWRkAtbmNovHzd+nUyK8cHJTYXffi4CmClPXPPTqGAaRbC/ yJf6JBEfMLK/6ps10eMwf7D/m5ZJUYIPJ1m7DmlUqjpr8R8v2bVbjqB//M9ig7KO yl/W5qzlBa2UAw/Gjgi0ITdDKs5sem7J8+PbVZKED5K0sD10YxZKMImCymJSlFkR gzqZi99qdAs8uhZ1K6h8ozkBLglxkT54IZ8Kn3LWwiQ0/I2xRNgX8Ugt1EQnrQM=3D =3DX+fU -----END PGP SIGNATURE-----