Re: [gentoo-user] Question on ebuild naming/numbering

[Ionen Wolkens <ionen@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1865 bytes --]

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 on the 
> gtk3 conversion.  It seems much of the work is being done in a specific 
> git branch.  If I want to create an ebuild to track that branch instead 
> of master, what would be an appropriate numbering of that ebuild?  Just 
> using a different name with 9999 would work - but then those two names 
> would have to block each other, since I don't think they could 
> co-exist.  Are there any examples I can look at?  Just adding something 
> after the 9999 doesn't seem right, nor does something like 9998.

If upstream is planning a specific version for that branch, it could be
used, e.g. with Qt we do dev-qt/qtbase-6.8.9999 for EGIT_BRANCH=6.8,
while 6.9999 is Qt6's main development branch.

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).

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.

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.

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.

And if that version is going to replace the old eventually, I wouldn't
do invasive workarounds like a separate package that blocks.
-- 
ionen

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]