Ludovic Courtès (2015-10-05 18:55 +0300) wrote: > Alex Kost <[email protected]> skribis: > >> Ludovic Courtès (2015-10-04 19:57 +0300) wrote: >> [...] >>> In that case, I would suggest something based on the URL at point rather >>> than the origin at point. >> >> It's neither URL at point, nor origin at point: it's like "C-c . b" but >> to download the source of the current package definition instead of >> building it. >> >> Also I don't understand how it can be based on the URL at point as >> instead of the full URL, we have something like this: >> >> (uri (string-append "http://.../foo-"; version ".tar.xz")) >> >> So currently to use "guix download", at first you need to manually >> construct the full URL. I find this inconvenient, that's why I want to >> have a command to download a source of the current package and to >> display its hash. > > Yes, that make sense. > > The problem I had in mind was that, when writing a new package > definition from scratch, you don’t know the SHA256 yet, but ‘sha256’ is > a required field of ‘origin’. So one would have to write a fake > ‘sha256’ value just for the sake of being able to use that feature, > which seems odd to me. > > See what I mean? How would you handle such a case?
I don't see a problem here, since a fake sha256 may be any string, for example "" (an empty string). Also I believe people begin to write a new package from some template, so you have a working skeleton of future package with all required fields from the very beginning. Then after filling an origin 'uri', you could "C-c . s" to download the source and get its hash. >>> However, if this is “too convenient”, I’m afraid this would give an >>> incentive to not check OpenPGP signatures when they are available. >> >> Sorry, I have no idea what it means :-( > > When upstream digitally signs its source code tarballs, packagers should > check those signatures to authenticate the code they have. > > If the tool makes it too easy to fill out the ‘sha256’ field without > going through the trouble of downloading the ‘.sig’ file and checking > it, then people will have an incentive not to check those signatures. Oh, now I see what you mean. Well, I don't know, I think if a user has a habbit to check a signature, he will check it anyway; and if not, then not. Besides, at first a packager needs to find an URL of the source tarball, so he will meet a signature anyway, if it exists. So it's up to him if he checks it or not. (I confess that I never check signatures) >>>> At first I also thought about building a package source and then to >>>> calculate the hash of the store file, but this way will lead to the >>>> wrong hashes for "snippet"-ed origins. Or do I miss anything? >>> >>> Well, I think bindings for ‘package-source-derivation’ would also be >>> useful, but IIUC this is not what you had in mind. >> >> If you mean to make a command to build the current package source, it >> can be done, although I don't see how it can be useful. > > It’s occasionally useful, similar to ‘guix build -S’ or the “Show” > button in package info buffers, except that it would operate directly on > the package at point. > > WDYT? Indeed, I agree. So if you don't mind the “download” command, then since there will be 2 commands for working with the source of the current package, what about the following key bindings for them: "C-c . s d" - to download the source (to know its hash) "C-c . s b" - to build it -- Alex
