Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 701292 - sys-kernel/git-sources - always bump to release too or join it with sys-kernel/vanilla-sources into one package
Summary: sys-kernel/git-sources - always bump to release too or join it with sys-kerne...
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Mike Pagano
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-11-27 05:25 UTC by jospezial
Modified: 2020-01-29 22:04 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jospezial 2019-11-27 05:25:57 UTC
I like it to have "The very latest -git version of the Linux kernel".

But with every release I have to emerge vanilla-sources or bump git-sources myself.

And then after first rc the stabilized versions of vanilla-sources screw up my installation.

As these share the same sourcecode I think the best would be to put these two packages into one and call it simply "linux-kernel"

With USE flags we could integrate other sys-kernel/*-sources with their patches, for example sys-kernel/gentoo-sources.

This would produce less data traffic and less maintenance on keeping the system up to date.

To control rc and releases what would be optimal, keywording or masking?

Dear maintainers, could you work together?

What do you think about it?
Comment 1 jospezial 2019-11-27 05:31:53 UTC
Could additionally live ebuilds of the kernel work?
Comment 2 charles17 2019-11-27 09:27:11 UTC
(In reply to jospezial from comment #1)
> Could additionally live ebuilds of the kernel work?

You might try using git sources directly, see
https://wiki.gentoo.org/wiki/Kernel_git-bisect#Get_the_git_sources
Comment 3 jospezial 2020-01-28 10:02:36 UTC
I was hoping to see sys-kernel/git-sources-5.5 release ebuild in the tree.
Any feedback from kernel team?
Comment 4 Mike Pagano gentoo-dev 2020-01-28 10:56:35 UTC
(In reply to jospezial from comment #3)
> I was hoping to see sys-kernel/git-sources-5.5 release ebuild in the tree.
> Any feedback from kernel team?

git-sources if for -rc versions
when the kernel is released it gets into the tree via vanilla-sources or gentoo-sources.

There would be ZERO difference between git-sources-5.5.0 and vanilla-sources-5.5.0. Duplicated that would be pointless. 

the next git-sources will be 5.6-rc1
Comment 5 jospezial 2020-01-28 23:54:19 UTC
(In reply to Mike Pagano from comment #4)
> (In reply to jospezial from comment #3)
> > I was hoping to see sys-kernel/git-sources-5.5 release ebuild in the tree.
> > Any feedback from kernel team?
> 
> git-sources if for -rc versions
> when the kernel is released it gets into the tree via vanilla-sources or
> gentoo-sources.
> 
> There would be ZERO difference between git-sources-5.5.0 and
> vanilla-sources-5.5.0. Duplicated that would be pointless. 
> 
> the next git-sources will be 5.6-rc1

As these share the same sourcecode I think the best would be to put git-sources and vanilla-sources into only one package.
How about that?
Comment 6 Mike Pagano gentoo-dev 2020-01-29 22:04:35 UTC
(In reply to jospezial from comment #5)
> (In reply to Mike Pagano from comment #4)
> > (In reply to jospezial from comment #3)
> > > I was hoping to see sys-kernel/git-sources-5.5 release ebuild in the tree.
> > > Any feedback from kernel team?
> > 
> > git-sources if for -rc versions
> > when the kernel is released it gets into the tree via vanilla-sources or
> > gentoo-sources.
> > 
> > There would be ZERO difference between git-sources-5.5.0 and
> > vanilla-sources-5.5.0. Duplicated that would be pointless. 
> > 
> > the next git-sources will be 5.6-rc1
> 
> As these share the same sourcecode I think the best would be to put
> git-sources and vanilla-sources into only one package.
> How about that?

I don't think that's a great idea.  I believe they should be separate.