From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 6D78B138334 for ; Mon, 19 Nov 2018 02:52:12 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0F853E09DD; Mon, 19 Nov 2018 02:52:07 +0000 (UTC) Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A47E5E09DA for ; Mon, 19 Nov 2018 02:52:06 +0000 (UTC) Received: by mail-pg1-f176.google.com with SMTP id t13so4482686pgr.11 for ; Sun, 18 Nov 2018 18:52:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=d9OhLKu1VS/cl7OCsv+OSrFyhBNxXmDjTp1n8h6KijE=; b=RfCsDn1fIkWU8NnSmZExQUrUGmf7txLHK3K+IRHvXTypXUXaRRiZz3ehVe6syk5BQC +Nxnzq7lb7ug2fHTY1fjkmAjc+zHr9z6q1aRWMyavdLkbyYX4OuwoviN6sy/cBD1aJmr X/X8yCpK3KfCJxX9A46OquSGoYh1+ctpJ7DtwZqqYnc8sL45qylDAN4AWjrSVaQg1u+Y feYMqk3DYzEo65Q6aI0dbwR6dbV2Lg7LQMpERTfWpYwb3J+cX9Pw4H9iEJtriWPI0Wy/ eaiIXkqKP2oc7ZMuK/JhTx+L/vmD14Ixq5MRPewwJJO/VdLl035x+YjJ/NRc/pnXWcFo nQDQ== X-Gm-Message-State: AGRZ1gKykCRT1KBddMTILMfUypegsSmANpwF4eqf+rER7rWnUa1eZ/D6 3IWnw4x6P3ks2MgH/YMmkK/lDyE/BsTDb3YSf1o= X-Google-Smtp-Source: AJdET5egrchcXoxIXkWIDvMAC12wn0XWy6Lwu74qRxN8m/vRHbWin6mWlWqXORGgBUlVko5wAzws1hEO3+5gXhxYzu0= X-Received: by 2002:a63:c42:: with SMTP id 2mr18572976pgm.372.1542595925145; Sun, 18 Nov 2018 18:52:05 -0800 (PST) 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 References: <8wbjQMoEQy/EntGTUihxxc@IqujqQJNQp+Tbney0Ttn8> <12d9221c-40a1-4271-b77f-85f61eeb424d@gentoo.org> In-Reply-To: <12d9221c-40a1-4271-b77f-85f61eeb424d@gentoo.org> From: Rich Freeman Date: Sun, 18 Nov 2018 21:51:53 -0500 Message-ID: Subject: Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format [gentoo@jonesmz.com] To: Zac Medico Cc: gentoo-dev Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 3ebe0461-4f3c-48bc-9e91-1cce5a6192fc X-Archives-Hash: a1afa22a6ae3b66db9166c4ea7eea0d3 On Sun, Nov 18, 2018 at 5:40 PM Zac Medico wrote: > > On 11/18/18 1:55 PM, Rich Freeman wrote: > > > > My idea is to basically have portage generate a tag with all the info > > needed to identify the "right" package, take a hash of it, and then > > stick that in the filename. Then when portage is looking for a binary > > package to use at install time it generates the same tag using the > > same algorithm and looks for a matching hash. > > We've already had this handled for a couple years now, via > FEATURES=binpkg-multi-instance. According to the make.conf manpage this simply numbers builds. So, if you build something twice with the same config you end up with two duplicate files (wasteful). Presumably if you had a large collection of these packages portage would have to read the metadata within each one to figure out which one is appropriate to install. That would be expensive if IO is slow, such as when fetching packages online on-demand. But, it obviously is somewhat of an improvement for Roy's use case. IMO using a content-hash of certain metadata would eliminate duplication, and based on filename alone it would be clear whether the sought-after binary package exists or not. As with the build numbers you couldn't tell from filename inspection what packages you have, but if you know what you want you could immediately find it. IMO trying to cram all that metadata into a filename to make them more transparent isn't a good idea, and using hashes lets the user set their own policy regarding flexibility. Heck, you could auto-gen symlinks for subsets of metadata (ie, the same file could be linked from a file that specifies its USE flags but not its CFLAGS, so it would be found if either an exact hit on CFLAGS was sought or if CFLAGS were considered unimportant). But, I'm certainly not suggesting that you're not allowed to go to bed until you've built it. :) -- Rich