Gentoo's SLOT concept is great! At the time being, sys-kernel/*-sources are single-SLOTted only. Let's take gentoo-sources as an example: . . . sys-kernel/gentoo-sources-4.4.31:4.4.31 is the latest long-term version. Enhance SLOT-ting to e.g. . . . sys-kernel/gentoo-sources-4.4.31:4.4/4.4.31 would enable following exactly this 4.4 long-term series with just a single line in . . . /etc/portage/package.keywords : . . . sys-kernel/gentoo-sources:4.4 and be done with it till EOL of this 4.4 LTB :: without looking out and enabling every new sub-release 4.4.xy :: without bothering about new major releases 4.Y.Z :: without enabling unwanted old versions via e.g. . . . <=sys-kernel/gentoo-sources-4.4.999-r99 The same applies to all other packages alike, therefore: . . . sys-kernel/*-sources Thanks a lot! P.S.: An other alternative, more general, but probably causing more effort, would be to introduce wild-cards into SLOT specifications. (This would involve the whole package tool-chain.)
(sub)slotting the package as you propose would not allow multiple versions in the same release series to be installed concurrently.
(In reply to Mike Gilbert from comment #1) > _multiple_ versions in the _same_ release series Thanks, Mike! Sorry - _that_ is the reason behind and the point I missed! Unfortunately, something like . . . sys-kernel/gentoo-sources:4.4.* does not work (yet) ("Invalid Atom"), only listing one sub-release = slot after another. Anybody any other / better idea besides . . . <=sys-kernel/gentoo-sources-4.4.999-r99 ?
(In reply to Mike Gilbert from comment #1) > (sub)slotting the package as you propose would not allow multiple versions > in the same release series to be installed concurrently. Plain slotting -should- work, right? I think the addition of some strategic virtuals might also be helpful. See also bug #497994 .
(In reply to Michael Everitt (IRC: veremitz) from comment #3) > (In reply to Mike Gilbert from comment #1) > > (sub)slotting the package as you propose would not allow multiple versions > > in the same release series to be installed concurrently. > Plain slotting -should- work, right? > Scratch that .. the penny dropped - you /might/ still want multiple sub-versions installed concurrently [eg. to test for progression/regressions/etc] Virtuals it is then ...
Created attachment 509774 [details] virtual/gentoo-sources-X.Y.ebuild This is a relatively crude, but simple first-cut of a major.minor 'virtual' for kernel branches. I have tested that it installs the latest in a series, and removes all but the latest with "emerge -c". Feel free to test, critique, improve as necessary... You will note that this simply needs naming with the Minor version you wish to track, and hence only needs creating when the first ebuild of a branch first lands.
(In reply to Michael Everitt (IRC: veremitz) from comment #5) > Feel free to test, critique, improve as necessary... Hi, Mihcael, first: thanks for joining in! Incorporating your ebuild as /usr/local/portage/local-overlay/ virtual/gentoo-sources/gentoo-sources-14.4.ebuild , running # ebuild gentoo-sources-14.4.ebuild digest , I get the following * ERROR: virtual/gentoo-sources-14.4::mkn_local_overlay failed (depend phase): * External commands disallowed while sourcing ebuild: * * Call stack: * ebuild.sh, line 620: Called source '/usr/local/portage/local-overlay/virtual/gentoo-sources/gentoo-sources-14.4.ebuild' '* gentoo-sources-14.4.ebuild, line 3: Called command_not_found_handle ' * ebuild.sh, line 88: Called die * The specific snippet of code: * die "External commands disallowed while sourcing ebuild: ${*}"
(In reply to Manfred Knick from comment #6) > (In reply to Michael Everitt (IRC: veremitz) from comment #5) Deleting (vim) the empty lines in your ebuild, digest works. Perhaps un-printable characters ?
(Addendum to comment #7) > un-printable characters ? :: No, but: Adding a comment sign "#" at the beginning of every empty line makes digest work. Adding even one empty line at the end of the ebuild already makes digest break. Strange! # eselect profile list | grep "*" [12] default/linux/amd64/17.0 *
(In reply to Michael Everitt (IRC: veremitz) from comment #5) > Feel free to test, critique, improve as necessary... A) Un-masking exactly the latest (~) version _manually_ is still necessary, otherwise the latest stabilized version will be taken. This once more relates to the discussion of enabling wild-cards for packages, like e.g. sys-kernel/gentoo-sources-4.14.* or sys-kernel/gentoo-sources:4.14.* already taking place in related Bugs. B) I have added "virtual/gentoo-sources" into my /usr/local/portage/local-overlay/virtual/linux-sources/linux-sources-3.ebuild as the first entry to the beginning of the list.
Created attachment 510476 [details] virtual ebuild with "#" into empty lines
Created attachment 510478 [details] example working with empty lines The main difference I recognize in virtual/gentoo-sources are - the lines with empty assignment ="" - the SLOT being assigned dynamically
(In reply to Michael Everitt (IRC: veremitz) from comment #5) > I have tested that it installs the latest in a series, and removes all but > the latest with "emerge -c". Guess it was the latest in a series without '~' ? If I - comment / remove sys-kernel/gentoo-sources:4.14.6 from my /etc/portage/package.accept_keywords/kernel , - emerge -aC sys-kernel/gentoo-sources , - emerge -auDN ... system world calculates : [ebuild N ~] sys-kernel/gentoo-sources-4.14.6 USE="-build -experimental -symlink" The following keyword changes are necessary to proceed: (see "package.accept_keywords" in the portage(5) man page for more details) # required by virtual/gentoo-sources-4.14::mkn_local_overlay # required by @selected # required by @world (argument) =sys-kernel/gentoo-sources-4.14.6 ~amd64 Thus, so far the "virtual" approach leveraged complexity - but the basic underlying problem to . . . (automagically) un-mask (exactly) the (latest|all) version(s) of a kernel release line has not been solved yet (c.f. title of this "bug"). :-(
Created attachment 510506 [details] virtual/gentoo-sources-X.Y.ebuild Two comments here:- 1) Firstly, my ebuild checks out fine with repoman and portage here, versions 2.3.3 and 2.3.13-r1 respectively, which suggest you have some strange download problem with the attachment (not completely unusual). This is quite obvious from your "repaired" files, which are double in size (bytes). Please re-check. 1.1) Oh, yes, indeed there is a discrepancy, because there has been an appendage of <CR> chars to the end of each line, where in *nix this should only be a <LF>. This is always one of the invisible dangers of copy/pasting to web! 2) Because of the way portage works, if you wish to use *unstable* as well as stable packages, you will have to tell portage that this is the case .. there is no easy way to do this within an ebuild. This is simple enough, as you should already have discovered, by adding a corresponding sys-kernel/gentoo-sources-X.Y* entry in your /etc/portage/package.keywords file/directory. Have another go .. its not gonna make the tea and do your shopping for you, but it should do as intended, with a bit of 'help' ;). Portage really isn't telepathic, sadly ...
(In reply to Michael Everitt (IRC: veremitz) from comment #13) > 1.1) Oh, yes, indeed there is a discrepancy, because there has been an > appendage of <CR> chars to the end of each line, where in *nix this should > only be a <LF>. This is always one of the invisible dangers of copy/pasting > to web! Confirmed .. its a weakness in Bugzilla .. copy/paste from the attachment, don't simply 'save' it because therein lies the problem.
(In reply to Michael Everitt (IRC: veremitz) from comment #14) Correct - verfied - but unfortunately, it still does not solve the underlying problem -> comment 12 (In reply to Michael Everitt (IRC: veremitz) from comment #13) > by adding a corresponding > sys-kernel/gentoo-sources-X.Y* entry in your /etc/portage/package.keywords > file/directory. Sorry for needing to put it straight: If I have to add that, your "virtual" is totally superfluous ... That's the point ! Kind regards Yours sincerely Manfred
Falling back to 'simple' : /etc/portage/package.mask : <sys-kernel/gentoo-sources-4.14 >sys-kernel/gentoo-sources-4.15 /etc/portage/package.accept_keywords/kernel : <sys-kernel/gentoo-sources:4.15 # 4.14.x = latest LTE This nearly resembles the missing wildcard construct > . . . sys-kernel/gentoo-sources:4.14.* (comment #2) (Michael Everitt in comment #5) > ... removes all but the latest This may not always be wanted. The above allows to keep older (source) versions until 'emerge --depclean' is commanded explicitly. Cleaning /usr/src needs manual 'rm -r' anyway because 'emerge --depclean' preserves the sub-directories /usr/src/linux-* with all files created during build.
It's been four years on this request. If someone is interested in producing a patch that solves the original ask please feel free to re-open.
