Re: Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format [gentoo@jonesmz.com]

[Rich Freeman <rich0@gentoo.org>]

On Sun, Nov 18, 2018 at 4:10 PM Roy Bamford <neddyseagoon@gentoo.org> wrote:
>
> Replying off list because I am not on the whitelist.

That seems odd.

> 1) append a uuid to each filename. Generated when the bin package file is generated.
> 2) encode the hostname of the machine that generated the file
> 3) encode the use flags in the filename.

So, I brought up this same issue in the earlier discussion and it was
considered out of scope, and I think this is fair.  The GLEP does not
specify filename, and IMO the standard for what goes INSIDE the file
will work just fine with any future enhancements that address exactly
this use case.

Besides your case of building for a cluster, another use case is
having a central binary repo that portage could check and utilize when
a user's preferences happen to match what is pre-built.

I suggest we start a different thread for any additional discussion of
this use case.  I was thinking and it probably wouldn't be super-hard
to actually start building something like this.  But, I don't want to
derail this GLEP as I don't see any reason designing something like
this needs to hold up the binary package format.  Both the existing
and proposed binary package formats will encode any metadata needed by
the package manager inside the file, and the only extension we need is
to encode identifying info in the filename.

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.  If a hit is found then
it reads the complete metadata in the file and applies all the sanity
checks it already does.  Generating of binary packages with the hash
cold be made optional, and portage could also be configured to first
look for the matching hash, then fall back to the existing naming
convention, so that it would be compatible with existing generic
names.  So, users would get a choice as to whether they want to build
up a library of these packages, or just have each build overwrite the
last.

Then the next step would be to allow these files to be fetched from a
binary repo optionally, and then finally we'd need tools to create the
repo.  But, this step isn't needed for your use case.  With the proper
optional switches you could utilize as much of this scheme as you
like.

Also, you could optionally choose how much you want portage to encode
in the tag and look for.  Are you very fussy and only want a binary
package with matching CFLAGS/USE/whatever?  Or is just matching
USE/arch/etc enough?  Some of the existing portage options could
potentially be re-used here.

Please make any replies in a new thread.

-- 
Rich