On 18/11/18 22:40, Zac Medico wrote: > On 11/18/18 1:55 PM, Rich Freeman wrote: >> On Sun, Nov 18, 2018 at 4:10 PM Roy Bamford <neddyseag...@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. > We've already had this handled for a couple years now, via > FEATURES=binpkg-multi-instance. Working fine for me for catalyst ARM runs ...
signature.asc
Description: OpenPGP digital signature
