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

[Jack <ostroffjh@users.sourceforge.net>]

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