From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id E5036158042 for ; Sat, 16 Nov 2024 22:51:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1B5EFE09C2; Sat, 16 Nov 2024 22:51:50 +0000 (UTC) Received: from mail-qv1-f45.google.com (mail-qv1-f45.google.com [209.85.219.45]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id CF2B2E09BA for ; Sat, 16 Nov 2024 22:51:49 +0000 (UTC) Received: by mail-qv1-f45.google.com with SMTP id 6a1803df08f44-6d415acf76aso6703296d6.0 for ; Sat, 16 Nov 2024 14:51:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731797509; x=1732402309; h=content-transfer-encoding:content-disposition:message-id :in-reply-to:mime-version:to:subject:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=OdbdAhMY+ijPtpKRK3SWlL3oWihvSUFaWiAJZigaJcw=; b=GYcNNT3+GIT11XUvqTdq81jFuMEmgpWs2DwGZhaxAeJGzayHmRheUfwUBFDVUSuVb3 RbYPYEAoF3ZfMaXsxHbUmb1kHwCIZ6dabkhXTyuHh7Kn0wPxkiMsHc10gHqI6C7gNoAU OXn27lGzKn0R8+RzLn+qaZ9VbKSWyIS0kTUtDROKZYNFGRepGtl47ebOoW9ByEQ1kU+/ Uzi8k93/dzGw8nx5PzXWNfS6taos3u8dmYz8537SRGJjK9/1rePvgsBJ9fI4F+BNiUgZ DO3tJcR2V77ROGmetP0ZeI7WF9A5qmhyw9aV+vzUS6UN6nnpzgBMbdTpAh0sH9Wzt1C+ c0jg== X-Gm-Message-State: AOJu0YygfCxLsO9Tk6a/CEbdcmi1VWNzIX+RqSie6ekHy+LFHGOX6IU3 H3M07B5yu2wZyKchXVyUh1sJ/952EkANzOOQNcnTpwBUWGGrvebSDaumBWqlsv3tisMIDumv1k9 q X-Google-Smtp-Source: AGHT+IEjeT2n3MH64A4sCWiXdVPRs6MowcX1WvrVXr9AI1iveHGI3ETKVmg5MzAwjhDQlimpgeGRKQ== X-Received: by 2002:a05:6214:2f8c:b0:6cc:11cc:6f36 with SMTP id 6a1803df08f44-6d3fb733e01mr102720806d6.3.1731797509060; Sat, 16 Nov 2024 14:51:49 -0800 (PST) Received: from ffortso9 (32-216-196-135.bng01.wlmn.ct.frontiernet.net. [32.216.196.135]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6d40dd86993sm14661816d6.101.2024.11.16.14.51.47 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 16 Nov 2024 14:51:47 -0800 (PST) Date: Sat, 16 Nov 2024 17:51:46 -0500 From: Jack Subject: Re: [gentoo-user] Question on ebuild naming/numbering To: gentoo-user@lists.gentoo.org Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 In-Reply-To: X-Mailer: Balsa 2.6.4-238-gb8ad7d4f7 Message-Id: Content-Type: text/plain; charset=ISO-8859-1; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 40c3e99a-11cb-4b83-82d9-63abb7ff5edf X-Archives-Hash: a7544d679a3506eb7a10f0008124351b Ionen, Thanks for the feedback. On 2024.11.16 17:33, Ionen Wolkens wrote: > On Sat, Nov 16, 2024 at 05:04:43PM -0500, Jack Ostroff wrote: > > There's been an update to the gkrellm mailing list about progress =20 > on the > > gtk3 conversion.=A0 It seems much of the work is being done in a =20 > specific > > git branch.=A0 If I want to create an ebuild to track that branch =20 > instead > > of master, what would be an appropriate numbering of that ebuild?=A0 =20 > Just > > using a different name with 9999 would work - but then those two =20 > names > > would have to block each other, since I don't think they could > > co-exist.=A0 Are there any examples I can look at?=A0 Just adding =20 > something > > after the 9999 doesn't seem right, nor does something like 9998. >=20 > If upstream is planning a specific version for that branch, it could =20 > be > used, e.g. with Qt we do dev-qt/qtbase-6.8.9999 for EGIT_BRANCH=3D6.8, > while 6.9999 is Qt6's main development branch. This is likely what I'll do, at least locally. Historically, there has =20 been enough activity in master that I wouldn't want to lose that by =20 just switching 9999 to the new branch. I suspect that there will be =20 very few if any other users interested, and at least for a while, this =20 will only track the slow decrease in compile errors, so I don't =20 actually see much reason to put this new ebuild in the tree. By the =20 time it actually compiles and runs, I wouldn't be surprised if it gets =20 merged into master, before becoming an actual release. >=20 > Doing it *before* rather than after can also be useful if don't want > that version to come out by default when someone accepts keywords > (aka take normal 9999 instead). >=20 > Not great but fwiw dev-vcs/git did do the "add something after" with > git-9999{,-r1,-r2,-r3} for branches maint, master, seen, and next > ... not quite sure who needs all these but well ;) with -r3 being > the most bleeding edge afaik. >=20 > One more option would be to make that branch the 9999 default and > not bother keeping both. I did that with qutebrowser when it switched > to Qt6 until they merged the changes to the main branch. >=20 > Ultimately it's not super important though, 9999 ebuilds should be > considered unsupported and is either only for the maintainers to track > changes or at most users that know what they're doing. So some > unintuitive versioning isn't the end of the world. >=20 > And if that version is going to replace the old eventually, I wouldn't > do invasive workarounds like a separate package that blocks. > -- > ionen >=20 Jack