From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 803D51389E2 for ; Mon, 29 Dec 2014 03:53:12 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D890BE0905; Mon, 29 Dec 2014 03:53:10 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 01F8AE0904 for ; Mon, 29 Dec 2014 03:53:09 +0000 (UTC) Received: from [192.168.1.4] (ip70-181-96-121.oc.oc.cox.net [70.181.96.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id DB2413405E8 for ; Mon, 29 Dec 2014 03:53:08 +0000 (UTC) Message-ID: <54A0D022.30701@gentoo.org> Date: Sun, 28 Dec 2014 19:53:06 -0800 From: Zac Medico User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@lists.gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-portage-dev@lists.gentoo.org Subject: Re: [gentoo-portage-dev] [RFC] New file layout for PKGDIR and binhosts References: <549A1C31.8040500@gentoo.org> <549EC172.80004@gentoo.org> In-Reply-To: <549EC172.80004@gentoo.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 7840e245-c1a0-4be3-a121-2b975f1117a7 X-Archives-Hash: 3bd9751fad10a36ffde8d7e02c84368a On 12/27/2014 06:25 AM, Rick "Zero_Chaos" Farina wrote: > On 12/23/14 20:51, Zac Medico wrote: >> Hi, >> >> As discussed in bug 150031 [1], it would be useful if PKGDIR could >> accommodate multiple binary packages built from the same source ebuild. >> Use cases for preserving multiple builds typically involve supporting >> multiple clients (with partially compatible configurations) from a >> single unified binhost. In this context, some of the reasons to retain >> multiple builds are: >> >> * Different USE flag combinations enabled (--newuse/--binpkg-respect-use >> needed) >> >> * Different versions of installed dependencies (EAPI 5 slot := operators >> needed) >> >> * Different repositories/overlays, with variance in the time of the last >> sync (--changed-deps/--binpkg-changed-deps needed if dependencies change >> due to eclass changes or ebuild modifications without revbump) > > I'm not saying don't take this into account, but in reality, this isn't > a problem we should have to deal with. Who is we? How do you know that whatever practices you use will also be utilized by everyone else out there? > if users want to rely on binpkgs > they should be syncing to the same rev the binhost used to generate > them. it's a reasonably trivial task to do this, even as simple as > daily webrsync or something. The --changed-deps/--binpkg-changed-deps are also useful for the same reason that emerge --dynamic-deps is enabled by default: * On the binhost server side, --changed-deps is an easy way to rebuild packages so the resulting binary packages have the latest deps, which may be necessary in order for the dependencies to be *satisfiable*. * On the binhost client side, --binpkg-changed-deps can be used to reject binary packages that haven't been rebuilt with the latest dependency specifications, avoiding inconsistent dependencies that may not be *satisfiable*. Sure, the --binpkg-changed-deps thing may not be needed for whatever limited use cases you are thinking of, but lets not force the same limits on everyone else. > To handle users with a different class or > ebuild version will prove difficult I believe, and worse, it will make > possibly dozens of extra binpkg revs for basically no reason. As discussed the above, these "extra binpkg revs" may be needed in order for the dependencies to be *satisfiable*. The cost of rebuilding packages can be considered negligible in comparison to the time that people would otherwise have to spend in order to manually resolve issues involving dependencies that are unsatisfiable. -- Thanks, Zac