Summary: | sys-kernel/linux-next-sources(?): new kernel package | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Haxk20 <haxk612> |
Component: | New packages | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | kernel, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | sys-kernel/linux-next |
Description
Haxk20
2021-09-27 22:43:48 UTC
While I'm not a member of kernel@, I suspect there'd be no objection _if_ you'd be willing to help out with keeping the ebuild working and handle maintenance where possible. You should be able to do this using the git-r3 eclass (look at any of the '9999' ebuilds in tree, and a lot of them will be suitable for you to base it on). (In reply to Sam James from comment #1) > While I'm not a member of kernel@, I suspect there'd be no objection _if_ > you'd be willing to help out with keeping the ebuild working and handle > maintenance where possible. > > You should be able to do this using the git-r3 eclass (look at any of the > '9999' ebuilds in tree, and a lot of them will be suitable for you to base > it on). (Also, feel free to come to the #gentoo-dev-help IRC channel on Libera if you want assistance.) Will do so. Also Ty for the very quick response :) Created attachment 742026 [details]
sys-kernel/linux-next
Something like this?
I installed in linux-next-9999 because there are tags like:
next-20210929
Not sure if they will ever make sense to ever have separate ebuild for that, but then we could install that one into /usr/src/linux-next-20210929
Thoughts?
(In reply to Mike Pagano from comment #4) > Created attachment 742026 [details] > sys-kernel/linux-next > > Something like this? > > I installed in linux-next-9999 because there are tags like: > > next-20210929 > > Not sure if they will ever make sense to ever have separate ebuild for that, > but then we could install that one into /usr/src/linux-next-20210929 > > Thoughts? linux-next-9999 should be fine as its indeed a live source updated daily. I dont think having always a new folder for each next update would be smart. I will give this a test soon. (In reply to haxk612 from comment #5) > (In reply to Mike Pagano from comment #4) > > Created attachment 742026 [details] > > sys-kernel/linux-next > > > > Something like this? > > > > I installed in linux-next-9999 because there are tags like: > > > > next-20210929 > > > > Not sure if they will ever make sense to ever have separate ebuild for that, > > but then we could install that one into /usr/src/linux-next-20210929 > > > > Thoughts? > > linux-next-9999 should be fine as its indeed a live source updated daily. > I dont think having always a new folder for each next update would be smart. > > I will give this a test soon. Thanks for testing. It's not so much a matter of "smart" or "dumb". It's more of , will a user request tagged linux-next versions as upstream names them? And if so, can we account for that here, which we have. (In reply to Mike Pagano from comment #6) > (In reply to haxk612 from comment #5) > > (In reply to Mike Pagano from comment #4) > > > Created attachment 742026 [details] > > > sys-kernel/linux-next > > > > > > Something like this? > > > > > > I installed in linux-next-9999 because there are tags like: > > > > > > next-20210929 > > > > > > Not sure if they will ever make sense to ever have separate ebuild for that, > > > but then we could install that one into /usr/src/linux-next-20210929 > > > > > > Thoughts? > > > > linux-next-9999 should be fine as its indeed a live source updated daily. > > I dont think having always a new folder for each next update would be smart. > > > > I will give this a test soon. > > > Thanks for testing. > > It's not so much a matter of "smart" or "dumb". It's more of , will a user > request tagged linux-next versions as upstream names them? And if so, can > we account for that here, which we have. Good point. And since users are always recommended to do a depclean after each update i think having it versioned would be OK. BUT that would require either an automatic tool to change the ebuild name to account for when the -next tree is updated. Which is usually every day except weekends. But it sometimes changes and sometimes there isnt a new version. IDK how we could account for that. Lets join the IRC so we dont have to spam the bug tracker :) I don't think creating another package is a good idea. Why do you such a package at all and don't just `git clone ...` in /usr/src for example? But if we do something like that, I would suggest to change existing sys-kernel/git-sources package. Make it dynamic. Use patches we do at the moment but add -9999.ebuild which uses git. People can now override EGIT_ variables to change repository, branch and stuff like that... The plan for now is to add linux-next as its own package for now. And when we get to it have it transition over to git-sources as a live package. This was talked about in IRC. Will mark it resolved once its done :) The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e059f7de3c4a4282a9ca7d9dc23b82e67c5b57b2 commit e059f7de3c4a4282a9ca7d9dc23b82e67c5b57b2 Author: Mike Pagano <mpagano@gentoo.org> AuthorDate: 2021-09-29 22:49:05 +0000 Commit: Mike Pagano <mpagano@gentoo.org> CommitDate: 2021-09-29 22:49:05 +0000 sys-kernel/linux-next: Support linux-next kernel Closes: https://bugs.gentoo.org/815199 Package-Manager: Portage-3.0.20, Repoman-3.0.3 Signed-off-by: Mike Pagano <mpagano@gentoo.org> sys-kernel/linux-next/linux-next-9999.ebuild | 33 ++++++++++++++++++++++++++++ sys-kernel/linux-next/metadata.xml | 11 ++++++++++ 2 files changed, 44 insertions(+) |