guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/4] emacs: Add 'guix-devel-download-package-source'.


From: Alex Kost
Subject: Re: [PATCH 2/4] emacs: Add 'guix-devel-download-package-source'.
Date: Tue, 06 Oct 2015 18:11:42 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Ludovic Courtès (2015-10-05 18:55 +0300) wrote:

> Alex Kost <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]