From: Rich Freeman <rich0@gentoo.org>
To: Zac Medico <zmedico@gentoo.org>
Cc: gentoo-dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format [gentoo@jonesmz.com]
Date: Sun, 18 Nov 2018 21:51:53 -0500 [thread overview]
Message-ID: <CAGfcS_mJGEn00_GuQ22SiARU-AiM4fgoCqi-krcyyD69wYZ74A@mail.gmail.com> (raw)
In-Reply-To: <12d9221c-40a1-4271-b77f-85f61eeb424d@gentoo.org>
On Sun, Nov 18, 2018 at 5:40 PM Zac Medico <zmedico@gentoo.org> 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
next prev parent reply other threads:[~2018-11-19 2:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-18 21:10 Fwd: Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format [gentoo@jonesmz.com] Roy Bamford
2018-11-18 21:55 ` Rich Freeman
2018-11-18 22:40 ` Zac Medico
2018-11-19 2:51 ` Rich Freeman [this message]
2018-11-19 18:45 ` Zac Medico
2018-11-19 10:45 ` M. J. Everitt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGfcS_mJGEn00_GuQ22SiARU-AiM4fgoCqi-krcyyD69wYZ74A@mail.gmail.com \
--to=rich0@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=zmedico@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox