From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id qBsWIb+YMGFSHgEAgWs5BA (envelope-from ) for ; Thu, 02 Sep 2021 11:26:23 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id YGzkHL+YMGEiRgAA1q6Kng (envelope-from ) for ; Thu, 02 Sep 2021 09:26:23 +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 05CC2444E for ; Thu, 2 Sep 2021 11:26:23 +0200 (CEST) Received: from localhost ([::1]:57306 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mLizF-0003mh-TZ for larch@yhetil.org; Thu, 02 Sep 2021 05:26:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51870) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLiz1-0003mK-NY for guix-devel@gnu.org; Thu, 02 Sep 2021 05:26:07 -0400 Received: from mailrelay.tugraz.at ([129.27.2.202]:56341) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLiyw-0004L7-29 for guix-devel@gnu.org; Thu, 02 Sep 2021 05:26:06 -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 4H0bBr0ZPsz3wNt; Thu, 2 Sep 2021 11:25:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1630574756; bh=0HyDPyMn0YYDmlgCC/mMNMJGAWBtrWRjjkWYf8qCbNw=; h=Subject:From:To:Date:In-Reply-To:References; b=Mcmimpx5Ttde/yl/rIqVXTYkrupQRPhX1mDDZft9A2oooZYEytcE5umQOFYNdiYOM Jz7jYSv3etZ3eAxR6iJh5AFiYsS8vH1CmJbxqlJwUP+hO/GKKszxNCVz4sJc4+kLVU eEjaIHN1lQADkxn1h5vozNJ+v5r22OQ657zlgspM= Message-ID: <602529fb7c902f8a77a69d86c00c70ddcc802c25.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: Thu, 02 Sep 2021 11:25:55 +0200 In-Reply-To: References: <52d2767d14f6e7f0f567265e0c1217057ce8bb54.camel@student.tugraz.at> <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: 7bit 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.117 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=1630574783; 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=0HyDPyMn0YYDmlgCC/mMNMJGAWBtrWRjjkWYf8qCbNw=; b=uGNLMEMJNM0XbYYkVhUE0zgJv4e16V48Bk5NyFkE5PfD2++p4HrrTp4Zbm0t79xjE9/7Wa ysbJoCS4hHK2362iFRz/BNIO9qmX/44yYDPJMksoqbQLC63zhj+4yc5daCme/wAZ/2vN46 ot8QlHP7hYnv0C2w6SfwWdpjWhPoMdcoJnoFpoGy4qS+S8LwN68FyhMQLiF1hvIPlR2GMZ j2i0pL3SXzfQAOG4kAkjppvM3m8uZaCXQKZgbViOnVZiRWWkt1sR8KEfU0QUEZYTJNDS3n T/Y7/cjmrQG29/8Mbxb4Cek9kufklit0bS2hqtjhQm5PPrNF3kDW/tkdvxwAUA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1630574783; a=rsa-sha256; cv=none; b=tIzICSYa45JpSMoEqwM70L4XVGwPPRPL9v5sVmd5nWXhhdBZojeTJNyLxeMvV5eOB7Qhht YcGvyj8jYToc1NYaVMw+ZqrBEdvwlyebyPESQ87W0/R9HsvXYJJZkNwHyOCrlewWJiVbBH 5VwPR81ySqcn+K0T4qTpOVlgSYrwwZxxmeAbpJEh+ru6Ap7GNEhbWgVbeLM6D1vKRAAfmL /GdJqvFB4HXUQClhrbJdr5x1CaqfqhiLk+knxRv2cMuJb3zJsntMO35oNFOQlQibfKMJo3 kFaDvmuM3R2CPH06kGAx4TrG+l02J1f5Zg9JFPnJik6T1r6b6XHk3DRJG7JQfQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=tugraz.at header.s=mailrelay header.b=Mcmimpx5; 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: -2.12 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=tugraz.at header.s=mailrelay header.b=Mcmimpx5; 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: 05CC2444E X-Spam-Score: -2.12 X-Migadu-Scanner: scn1.migadu.com X-TUID: UIcwskQddNJL Am Donnerstag, den 02.09.2021, 07:53 +0000 schrieb Jonathan McHugh: > Hi Liliana, > > Given your examples I expect improving upstream CHANGELOG (or third > party) files would be too much of a burden in order to solve the > aforementioned problems. ChangeLogs are generally not installed as part of packages, though some packages might include them as documentation. In other cases, they might even be part of the source files themselves, Emacs packages sometimes function like that. In either case, they only "address" the problems insofar as reading them might give a clue about what goes into the resulting binary, but they do not help that much with versioning. > > Jonathan > > September 1, 2021 11:47 PM, "Liliana Marie Prikler" < > leo.prikler@student.tugraz.at> wrote: > > > 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.