Currently, I want to keyword all 4.1.x release but NOT all 4.1* (like a future 4.10.x that could appear). What is the way of allowing that? It seems that is not allowed for some reason :( --- Invalid atom in /etc/portage/package.keywords/zz: =sys-kernel/gentoo-sources-4.1.* Thanks a lot
Since portage-2.2.20, 4.1* behaves as you want: https://gitweb.gentoo.org/proj/portage.git/commit/?id=d4966a381ee4577818bd972946647338046715b1 *** This bug has been marked as a duplicate of bug 560466 ***
And, what is wrong with 4.1.* form? It looks much more intuitive to me and I am not sure why it's not allowed :/
(In reply to Pacho Ramos from comment #2) > And, what is wrong with 4.1.* form? It looks much more intuitive to me and I > am not sure why it's not allowed :/ There's nothing wrong with it, except that it's invalid according to PMS.
Of course, we could extend the syntax in a future EAPI.
(In reply to Zac Medico from comment #4) > Of course, we could extend the syntax in a future EAPI. Should I reopen this then? Thanks :)
I would expect 4.1.* to match 4.1.x but not 4.1. Is that what you expect?
MAybe I am forgetting some case... but the cases I remember should be covered with that as they will have x.y.0 versions too
Let me ask a different question: is there a specific use case for x.* that would be distinct from x*? Remember that x* accepts any values for the components following x, not a wildcard of x*; e.g. 4.1* matches 4.1_rc1, 4.1, 4.1.0, 4.1.1... I'm rather opposed to having additional wildcard-thingie with different behavior unless absolutely necessary, and I'd rather not get into specific version separators that are bound to produce even more confusion.
IMHO the confusion arising from a 4.1.* wildcard matching 4.1.1 and 4.1.2 but not 4.1 and 4.1_p1 would outweigh any benefit. Consequently we should also have 4.1_* then, for matching 4.1_pre1 and 4.1_p1?
(In reply to Ulrich Müller from comment #9) > IMHO the confusion arising from a 4.1.* wildcard matching 4.1.1 and 4.1.2 > but not 4.1 and 4.1_p1 would outweigh any benefit. I do not think there would be much confusion... if you see a dep like 4.1.* , we will expect it to not cover 4.1 (without the last dot). This would cover lots of upstream versioning systems that, when they are relying on three numbers, they use to release 4.1.0 versions instead of plain 4.1 Also, the downside of not covering a 4.1 version looks softer to me than implicitly covering all 4.1 versions, all 4.10, 4.11, 4.11... and anything the 4.1* construct will force us to handle
(In reply to Pacho Ramos from comment #10) > Also, the downside of not covering a 4.1 version looks softer to me than > implicitly covering all 4.1 versions, all 4.10, 4.11, 4.11... and anything > the 4.1* construct will force us to handle 4.1* does _not_ match 4.10 or 4.11. We fixed that some time ago, see bug 560466.
I'm aware this is an old issue, but it seems to be related to my question. Why don't the kernels just use a slot for the "main" version like 4.14, 4.15, etc and subslots for the (bug)fix releases? That seems like quiet a natural fit? Or is there something that prevents this from working properly?
Closing per comment #11. *** This bug has been marked as a duplicate of bug 560466 ***
