| 1 |
On 11/18/18 1:55 PM, Rich Freeman wrote: |
| 2 |
> On Sun, Nov 18, 2018 at 4:10 PM Roy Bamford <neddyseagoon@g.o> wrote: |
| 3 |
>> |
| 4 |
>> Replying off list because I am not on the whitelist. |
| 5 |
> |
| 6 |
> That seems odd. |
| 7 |
> |
| 8 |
>> 1) append a uuid to each filename. Generated when the bin package file is generated. |
| 9 |
>> 2) encode the hostname of the machine that generated the file |
| 10 |
>> 3) encode the use flags in the filename. |
| 11 |
> |
| 12 |
> So, I brought up this same issue in the earlier discussion and it was |
| 13 |
> considered out of scope, and I think this is fair. The GLEP does not |
| 14 |
> specify filename, and IMO the standard for what goes INSIDE the file |
| 15 |
> will work just fine with any future enhancements that address exactly |
| 16 |
> this use case. |
| 17 |
> |
| 18 |
> Besides your case of building for a cluster, another use case is |
| 19 |
> having a central binary repo that portage could check and utilize when |
| 20 |
> a user's preferences happen to match what is pre-built. |
| 21 |
> |
| 22 |
> I suggest we start a different thread for any additional discussion of |
| 23 |
> this use case. I was thinking and it probably wouldn't be super-hard |
| 24 |
> to actually start building something like this. But, I don't want to |
| 25 |
> derail this GLEP as I don't see any reason designing something like |
| 26 |
> this needs to hold up the binary package format. Both the existing |
| 27 |
> and proposed binary package formats will encode any metadata needed by |
| 28 |
> the package manager inside the file, and the only extension we need is |
| 29 |
> to encode identifying info in the filename. |
| 30 |
> |
| 31 |
> My idea is to basically have portage generate a tag with all the info |
| 32 |
> needed to identify the "right" package, take a hash of it, and then |
| 33 |
> stick that in the filename. Then when portage is looking for a binary |
| 34 |
> package to use at install time it generates the same tag using the |
| 35 |
> same algorithm and looks for a matching hash. If a hit is found then |
| 36 |
> it reads the complete metadata in the file and applies all the sanity |
| 37 |
> checks it already does. Generating of binary packages with the hash |
| 38 |
> cold be made optional, and portage could also be configured to first |
| 39 |
> look for the matching hash, then fall back to the existing naming |
| 40 |
> convention, so that it would be compatible with existing generic |
| 41 |
> names. So, users would get a choice as to whether they want to build |
| 42 |
> up a library of these packages, or just have each build overwrite the |
| 43 |
> last. |
| 44 |
> |
| 45 |
> Then the next step would be to allow these files to be fetched from a |
| 46 |
> binary repo optionally, and then finally we'd need tools to create the |
| 47 |
> repo. But, this step isn't needed for your use case. With the proper |
| 48 |
> optional switches you could utilize as much of this scheme as you |
| 49 |
> like. |
| 50 |
> |
| 51 |
> Also, you could optionally choose how much you want portage to encode |
| 52 |
> in the tag and look for. Are you very fussy and only want a binary |
| 53 |
> package with matching CFLAGS/USE/whatever? Or is just matching |
| 54 |
> USE/arch/etc enough? Some of the existing portage options could |
| 55 |
> potentially be re-used here. |
| 56 |
|
| 57 |
We've already had this handled for a couple years now, via |
| 58 |
FEATURES=binpkg-multi-instance. |
| 59 |
-- |
| 60 |
Thanks, |
| 61 |
Zac |
Archives