From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 29 15:10:55 2021 Received: (at 50620) by debbugs.gnu.org; 29 Sep 2021 19:10:55 +0000 Received: from localhost ([127.0.0.1]:50270 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVeyk-0001vr-K1 for submit@debbugs.gnu.org; Wed, 29 Sep 2021 15:10:55 -0400 Received: from mail-wm1-f68.google.com ([209.85.128.68]:41721) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVeyh-0001va-IE for 50620@debbugs.gnu.org; Wed, 29 Sep 2021 15:10:53 -0400 Received: by mail-wm1-f68.google.com with SMTP id g19-20020a1c9d13000000b003075062d4daso2519328wme.0 for <50620@debbugs.gnu.org>; Wed, 29 Sep 2021 12:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=/rF2ZpWoz5okrdZI5+WyqU3igx44TfO4VAxxv/wl8qc=; b=kNglubXCRPg/UvyjrXbqy7YOnn0si4UGUSpsmwEjc9yVxuViRMb6ly4TAdhRKrbf8E PWdjDgziFsoePyfPqa+GwlAQZHhGilSSfYWtOfdij8ez4VYW/DwD9T0CRdC4Y00N+idh SKdePpY7bPa2sugVQDWUnUwJ28uKHXWOvdIghSrnkXCnzSwWWtExoqc89eoABSeIYluh r7KGN8yUbsPkSnvheNZ5lMhG+Pe0shSNnI1HPhf+2vT7XKN2ja2pfAAmsol0ff316n/z 5qCcdNPIub6yihLk7GgV4GWfZjZwgijS17xyEwXSP47CQO0KsBEUEqvPKIF9avwDv3LG Q1Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=/rF2ZpWoz5okrdZI5+WyqU3igx44TfO4VAxxv/wl8qc=; b=KbioswspTBTcip50GUPrtDCNpTnoRrhzvH+B4bPzLx/ycOAZPWTvCUbjecoX2CuBL3 6nuEvFKMXskqmQ0nEUkPe0VJYePqLUtrZAAGfk0hO896C7GACsCUnx8zn3J7Fo6oLwtj 3UrcU0f0ucNG1TKr1KRjX/sIzEKZ7u/DIHE6Ge28VLA0D8ZS+TusO4CLpW3YUiFDZAsh vc8M2js/2IVz579Yf3KF/IBa6Yd3339ScmNZAejoPqOpMkMH3UzT8baLdBuU1GerNiIO xBdPQ2ZjBtPatShNI9c4XRgMqQekz5uh/f4KJZuZM6OxedJ/HT4h/4EHl/DS2vkckkl1 47VA== X-Gm-Message-State: AOAM5303Hz04JcZ/gsn3xDvZwQkXt4/1d1e4D841ztSW+j+bQU4W/zAV Rro6rPzpt9LMgJk3A8st77Y= X-Google-Smtp-Source: ABdhPJyF+9hxNuFFzGou9NM6LtFt+NkygoMV8qGs6/VqNKOQPALr7Od8+mT0b8Lp5Ald6pwq25Q+nw== X-Received: by 2002:a1c:2082:: with SMTP id g124mr837300wmg.192.1632942645628; Wed, 29 Sep 2021 12:10:45 -0700 (PDT) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id m29sm714735wrb.89.2021.09.29.12.10.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Sep 2021 12:10:45 -0700 (PDT) Message-ID: Subject: Re: [PATCH 1/2] guix: packages: Document 'computed-origin-method'. From: Liliana Marie Prikler To: zimoun Date: Wed, 29 Sep 2021 21:10:43 +0200 In-Reply-To: References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <87v930ay5y.fsf@netris.org> <87pmstghx0.fsf@netris.org> <1803ff0456849f456c6994d47cbe50d1a8ff6a09.camel@gmail.com> <56dcce10a751153d89f515028cd18c9125f6b84f.camel@gmail.com> <756ae01852047a7adc2522c025c8cd7283dc7e55.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: Mark H Weaver , 50620@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi, Am Mittwoch, den 29.09.2021, 19:48 +0200 schrieb zimoun: > Hi, > > On Wed, 29 Sept 2021 at 16:36, Liliana Marie Prikler > wrote: > > > > Perhaps I am wrong about option (2) -- my claim is that > > > computed-origin-method is *always* used with a promise so it is > > > for sure an half-baked guess but enough; and it avoids to hard > > > code the modules from where the packages come from. Therefore, > > > option (2) does not improve, IMHO. > > > > The probability of having a promise when using computed-origin- > > method is 100%. What is the probability of having computed-origin- > > method when you see a promise? The answer is: we don't know. We > > can see from the > > You mean, what is the probability of having a computed-origin-method > when the origin-uri is a promise? We do not know, but pragmatically, > for now 100%. :-) > > Option (2) is: > > ___ (or (eq? method (@@ (gnu packages gnuzilla) computed-origin- > method)) > _______ (eq? method (@@ (gnu packages linux) computed-origin- > method))) > > then I ask you similarly: what is the probability of having packages > using computed-origin-method in these 2 modules only? We do not > know, > but pragmatically, for now 100%. :-) > > The hypothetical probabilities to evaluate are: > > - what would be the probability that a new package having a promise > as origin-uri is not indeed a package with a computed-origin-method? > vs > - what would be the probability that a new package using > computed-origin-method is not part of either (gnu packages gnuzilla) > or (gnu packages linux)? > > Anyway! Well, I am not convinced that it is worth to tackle these > hypothetical issues. :-) I meant that only in reference to a comparison of your original patch in #50515 vs. option (2). Option (2) is conservative, it only detects computed origin which it knows how to handle. Your original patch is more liberal in that it detects anything that has a promise as uri as a computed origin, which might however not have the same semantics as those two copies of the same code. Obviously, both (3) and (3a) don't have this problem, but they're also conservative in that e.g. I could roll my own channel with the exact same computed-origin-method copypasta'd once more and it wouldn't be detected, though that's probably off-topic.[1] > That's why the option (3): > > (eq? method (@@ (guix packages) computed-origin-method)) > > which means refactorize*. It is somehow the two worlds: check i.e., > safer, no modules hard-coded and keep private the time to have The > Right Plan for this computed-origin-method. I was a little confused when I read factorize from Ludo or refactorize from you. I know this technique under the name "refactoring". > *refactorize: I think (guix packages) is better because it defines > '' and other tooling friends. Because > 'computed-origin-method' is somehow a temporary tool about origin, > i.e., a mechanism to define packages, it makes sense to me to put it > there. However, (gnu packages) is about tools to deal with packages, > not to define them; although one could argue that 'search-patch' is > there is used to define package. For what my rationale behind the > choice of (guix packages) is worth. And indeed, I have only > half-mentioned this rationale. To that I would counter, that (guix packages) only defines package and origin records and how to compile them to bags and derivations. All the methods through which those fields are filled are defined outside, be it the occasional local-file used in "Build it with Guix"-style recipes or the closer to our methods svn-fetch and git-fetch. Were it not for the fact that it uses procedures defined in (guix packages), you might have a better time reasoning that this should be a hidden part of (guix gexp), but since it does, it would introduce a cycle if you did. While (gnu packages) does offer "tools to deal with packages" as you put it, I'd argue the way it does is in establishing a namespace for them (fold-packages etc.) and that this namespace (the "GNU namespace") is the best location for computed-origin-method. The reason we use computed-origin-method at all, is because as GNU Guix we take a hard stance on the FSDG and do our damndest not to lead users to nonfree software. This includes producing clean --source tarballs. Were it not for that, we could easily deblob at build time, and this is an important observation to make, because it means that projects that don't need this level of control can "safely" defer it the way we do currently for "unpack more after unpack".[2] In other words, I strongly believe that users of compute-origin-method do the hard work of computing origins to follow GNU standards and will thereby have no issue referencing the GNU namespace to get to it. > As I said, generating this sources.json file by the website is > clunky. > Somehow, it is a quick hack to have something up waiting The Right > Way; the long-term generations should be done through the Data > Service, as it had been already discussed but not yet implemented. > Help welcome. :-) I have no opinion on that as I don't work on the Data Service. > > > About update guix package [2/2], it has to be done, IIUC. The > > > file > > > sources.json contains what the package guix provides, not what > > > the > > > current Guix has. The website -- built using the Guile tool > > > haunt -- > > > uses Guix as a Guile library. Maybe I miss something. > > > > What I was trying to say was that you wouldn't need to rebuild the > > guix package before applying the 50515 changes, which this one > > seems to require. Again, I'm not 100% sure that's the case, but > > IIUC (gnu packages) is its own realm in this regard. > > Hum, maybe there is a misunderstanding here. On one hand 50620 > applies to the guix.git repo and on the other hand 50515 applies to > guix-artwork.git repo. Oh, I somehow missed that completely. Oops. > To have the sources of linux-libre and icecat reported in > sources.json and thus to get a chance to have them archived by SWH, > we need: > > a- if computed-origin-method is factorized then update the guix > package (Guix as a library) else do nothing; patch applied to > guix.git > b- tweak how sources.json is built; patch applied to guix- > artwork.git > > Well, the aim of 50620 is to deal with a) whereas the aim of 50515 is > to deal with b). Note that 50515 requires a v2 if > computed-origin-method is factorized. > > Maybe I miss something. From my understanding, all the modules are > part of Guix as a library. Therefore, it does not depends on where > we refactorize. No, no, I was wrongly under the impression that this sources.json would be generated by Guix itself what with all the other SWH interaction we already have. Again, a mistake on my part. > To be honest, I thought that this tiny improvement of the SWH > coverage would have been much more easier and that that trivial task > would not have taken more than 15 days with lengthy discussions. :-) To be honest, part of the lengthy discussion was me being confused about your intent – in multiple ways. If you wanted a "quick and dirty fix" you could have went with checking those two modules explicitly on the guix-artwork side and it would have had a fairly small impact. Reading this patch first and the discussion second, I had assumed your intent was rather to formalize a method that had hitherto only been used informally and the move to the guix namespace amplifies that imo. All the best, Liliana [1] The only solution is of course to compare via equal? instead of eq?, which if implemented for functions would be Turing-hard :) [2] Of course, this assumes that other projects don't want to actually unpack dependencies when using --source, but I think it's likelier they will just use recursive submodule checkout.