[gentoo-user] Question on ebuild naming/numbering

[gentoo-user] Question on ebuild naming/numbering

[Jack Ostroff]

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.

Any thoughts or suggestions?

Thanks.

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

[Ionen Wolkens]

[-- 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 --]

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

[Jack]

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  
> 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.
This is likely what I'll do, at least locally.  Historically, there has  
been enough activity in master that I wouldn't want to lose that by  
just switching 9999 to the new branch.  I suspect that there will be  
very few if any other users interested, and at least for a while, this  
will only track the slow decrease in compile errors, so I don't  
actually see much reason to put this new ebuild in the tree.  By the  
time it actually compiles and runs, I wouldn't be surprised if it gets  
merged into master, before becoming an actual release.

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

Jack