From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id QmOmIAX1L2FseQEAgWs5BA (envelope-from ) for ; Wed, 01 Sep 2021 23:47:49 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id QOuzGwX1L2FINAAAB5/wlQ (envelope-from ) for ; Wed, 01 Sep 2021 21:47:49 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 187981B0B8 for ; Wed, 1 Sep 2021 23:47:49 +0200 (CEST) Received: from localhost ([::1]:43014 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mLY5E-0000pS-5j for larch@yhetil.org; Wed, 01 Sep 2021 17:47:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41362) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLY4u-0000oz-Ln for guix-devel@gnu.org; Wed, 01 Sep 2021 17:47:31 -0400 Received: from mailrelay.tugraz.at ([129.27.2.202]:36738) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLY4r-0003bo-9j for guix-devel@gnu.org; Wed, 01 Sep 2021 17:47:27 -0400 Received: from nijino.local (194-118-34-199.adsl.highway.telekom.at [194.118.34.199]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4H0Hhh1wkGz3wV3; Wed, 1 Sep 2021 23:47:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1630532836; bh=2Qef47INXTrxOdyScJUhhY6xSQ0R1PcCcWtIATjYHtI=; h=Subject:From:To:Date:In-Reply-To:References; b=TcnlvEdHbFuood3/iuO9sjcvlKU6xmx2h6lPOplTCfn2Va1GLXvFYP/WpgY7h9XPl E8ixPPJFML6bTACJOZ6BY5poGHAi4D886Oli5krOkJ1tmUKS4Z4ltiCV2OrRNMGwPA MHfxnzVdc6R0LtHUIh1lYENSgXk/6cZY3JPPQp/c= Message-ID: <52d2767d14f6e7f0f567265e0c1217057ce8bb54.camel@student.tugraz.at> Subject: Re: Can we find a better idiom for unversioned packages? From: Liliana Marie Prikler To: Jonathan McHugh , Maxime Devos , Sarah Morgensen , guix-devel@gnu.org Date: Wed, 01 Sep 2021 23:47:15 +0200 In-Reply-To: <6c1542b14a505e797a6d605d63796833@libre.brussels> References: <27af2d4efec4ced1e8411b1d993dbc8112d26cb7.camel@student.tugraz.at> <8635qp1j6k.fsf@mgsn.dev> <473ea45f79b94ff04327f3fdf691dd8e4a85f7ba.camel@telenet.be> <1e58de895f638d897ea89647344ef24c40ea3ec2.camel@telenet.be> <6c1542b14a505e797a6d605d63796833@libre.brussels> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116 Received-SPF: pass client-ip=129.27.2.202; envelope-from=leo.prikler@student.tugraz.at; helo=mailrelay.tugraz.at X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1630532869; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=2Qef47INXTrxOdyScJUhhY6xSQ0R1PcCcWtIATjYHtI=; b=EKv44a8NNTS9+JYOiSCwFJDt2iRKCkMKBlFCAE5c408shSEyn2QJTKOAOAZb0UYptUqgfY /PGZ4Onlg1JWLn3zQ3se6fX3gc5vj8fVTOguqzxSHsjSpHYT80SiiVr6Cc1wKrXxaZ8ii3 1EVqgybKrFX0NCtwD+ApsxWviqCgMKhLnI5mKiON9or0QcMVoE3CXEyYSdFE2N+ffb61Xw 4PgRGdtO83MxEAXx6+eXi5b/+Ke/56xKjJWwIo2t6j8LgkFIoICqICNIqmn7US7TX/0JWK 3vlmjvi0cMSFB14BduWFfA/95VDrC1alHsifgJq81xKTDSQbPPTmKq73RsKtHw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1630532869; a=rsa-sha256; cv=none; b=oEGZi8f9ol22f6nPpZHRncmN3z+oiDVH6qKNQVA7vKRWYXJaxzQi2hDUlvJAzTxTXqms+M 3/ldCIf0F9WN4xQTmpxKgMv6Bbie8EOaUh11Yvr2FNlFhikLSUSJ8EQTxOeYe57v5MfnVg iga9jVmdSXQRHEv4Jf+0IMBUr7Vt9rRiDcX6PWPLR8bcj0iUthP4DAHQ2/2F1CKgmH+l+O XGQ7n0mtEgLdsSYoYoUE5NRBTo7tAuv9V3SZ6iQ0FfqIZOV23mWClinEPF/Fgpe1qRz8eH M5dHjmejvNpYSv6wGP212RAz3NGc2+cZVpLBYJk5ykBbXQzjfgvM1Oo1T5MP3A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=tugraz.at header.s=mailrelay header.b=TcnlvEdH; dmarc=pass (policy=none) header.from=student.tugraz.at; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -0.62 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=tugraz.at header.s=mailrelay header.b=TcnlvEdH; dmarc=pass (policy=none) header.from=student.tugraz.at; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 187981B0B8 X-Spam-Score: -0.62 X-Migadu-Scanner: scn1.migadu.com X-TUID: qIvxp//ofQI0 Am Mittwoch, den 01.09.2021, 19:48 +0000 schrieb Jonathan McHugh: > September 1, 2021 8:35 PM, "Liliana Marie Prikler" < > leo.prikler@student.tugraz.at> wrote > > > Making our rando commit git versions look like such other distro > > versions does come at a disadvantage though, particularly when we > > look > > at it through the lense of someone not used to Guix' versioning > > scheme. > > Instead of telling us "yeah, this is the Nth time we picked a rando > > commit since the last release and this time it's de4db3ef", users > > coming from such distros would assume "oh well, this is still good > > ol' > > 1.0 with some more patches applied". So while the commit itself > > does > > not give us any particularly useful information (unless you're that > > person who uses this part of the version string to look the commit > > up > > on hubbucket), especially not when thinking in the context of > > versioning scheme, it does provide the existential information of > > "hold > > on, this is not a release commit, it's something else" and might > > thus > > direct users to be a little more attentive when they'd otherwise go > > "yep, upstream considers this solid and Guix considers it even more > > solid, so it's the solidest". Note, that this can be overcome both > > by > > teaching/learning about it and by using a special sigil as > > mentioned > > above. > > Perhaps a function revealing metadata based upon the version string > would allow more people get an overview without visiting hubbucket^1? I don't think that information is actually encoded anywhere nor immediately obvious unless you're vaguely familiar with said software, but it's still important e.g. if reading the documentation. Does this feature mentioned in the frobnicatorinator 1.44 docs apply to 1.36 or not? Do the examples from some book written in the early 70s work if I compile them with GCC 12? And so on and so forth. > Would that be any weirder and awkward for workflows than the command > `guix download'? > => > https://guix.gnu.org/manual/en/html_node/Invoking-guix-download.html Imo the only thing awkard about guix download is that it only handles tarballs when a large chunk of packages use some sort of version control. We might want to look over that at some point and specify revisions/commits to download on the command line. > Even better, highlighting the part of the string and launching an > appropriate context in Emacs-Hyperbole > > My personal answer to this might be a disappointing one, as in that > > case I believe we wouldn't even need procedures like git-version to > > form them, but could instead use - > > as a mere convention like many more popular distros already do. If > > the dash is overused for that, we could also use a different > > symbol, though perhaps there's not that many on a typical US > > keyboard to reserve one as a revision delimiter. > > # Apologies for being off topic > The inclusion of that character '£' on keyboards bothers me - Ive > never seen anybody use it (though maybe I have some fuzzy memory with > regards to the Commodore 64). Pretty sure people in the UK used it for their currency even pre- Brexit, but if you're used to $ for everything it might be understandable why you're confused. > If it unfortunately is on an international band of keyboard classes > consider it as a delimiter. Otherwise Im ripping out that button and > never interfacing the number 3 again. Are you okay? > ^1 Is that pronounced bouquet? > => https://keepingupappearances.fandom.com/wiki/Hyacinth_Bucket I regret clicking on that. While bucket and bouquet are etymologically related, at least according to Wiktionary, I'd assume the generally accepted pronunciation would be /hʌbˈbʌkɪt/, though there may be local variations.