IRC channel logs
2022-10-13.log
back to list of logs
<civodul>zimoun: hi! the 1st issue above doesn't mention the format though, or did i miss it? <civodul>if would be great if they would add nar as a serialization format :-) <zimoun>about NAR, it is already almost the case. ;-) Antoine use some external ’nix-nar’ tools and would like a Python replacement. <zimoun>Well, SWH seems okish to store NAR somewhere. And it would help for looking up (instead of complex SVN tricks) <zimoun>civodul: another question I have is: why Guix is plain serializer for tarball and nar serializer else? <civodul>that'll make things considerably easier if SWH supports nar hashes <civodul>"plain" serializer is enough for a regular file like a tarball <civodul>(as in: not limited to Nix and Guix) <zimoun>hum, your argument is not convinced me. ;-) Since then the hash is nix-base32 which not universal. <civodul>converting from nix-base32 to hex is trivial <civodul>whereas one cannot "convert" from a nar hash to a git hash or plain hash <civodul>it's important because we resort to content-addressed mirrors besides SWH <civodul>alright, in practice these are mirrors provided by Guix, NixOS, and SWH <zimoun>because I try to explain how it works and it appears to me inconsistent. <zimoun>Well, maybe it could be something to add to Disarchive: a bridge (map) between different serializers. <zimoun>Today, we use plain (which is more or less tar), nar and git (which is also swh, at least now). On the top of that, different hash algorithms. <zimoun>One simple piece is missing for whatever reason and paf many things fall down, IMHO. <civodul>we only use the nar and "plain" serializers in practice <civodul>we use the Git serializer indirectly, because we refer to commit IDs, but that's it <zimoun>if we encode Git commit hash in package definition (instead of label tags), we could directly swh:rev identifier to lookup. And it will fix some SWH snappshot issues. <civodul>right; git-fetch origins often refer to commit IDs, but sometimes refer to tags <civodul>in the latter case, we do have a fallback mechanism that works well with SWH <civodul>the "only issue" is if the tag was modified <civodul>and that's why we should consider not referring to tags (this has been discussed a few times) <civodul>funny: the nar vs. git serialization issue was one of the first i raised when SWH went public :-) <civodul>so it's really great news that you have here <zimoun>yeah, url+tag works well with SWH but we discussed several corner cases – speaking about SWH snapshots and so on. It appears to me an hard path, especially for maintenance, when we could encode (at package time), the information necessary for the lookup. <zimoun>Well, seing the flame, it would be hard to have an inclusion in package definition <civodul>also, which corner cases do you have in mind? *civodul missed a few things it seems :-) <zimoun>I do not have the list at hand but some packages are not reachable even if they already are in SWH. <zimoun>Some others are bugs on SWH side, I guess. ;-) <civodul>i guess we need to look at specific examples to understand what's wrong <civodul>as for the long thread above, it probably includes valid arguments somewhere in the middle :-) <civodul>anyway, the day we can look up SWH "content" or "directory" objects by nar hash, all our problems vanish <efraim>interesting story about SWH backups, I have an unmaintained channel with IETF RFCs in text form and one of them disapeared from the official website. SWH has a backup of it <civodul>neat; it's good to know that it works in practice :-) ***Server sets mode: +nt