[gentoo-user] emerge latest in a certain version series of a package

[gentoo-user] emerge latest in a certain version series of a package

[Thanasis]

Is there a way to specify that I want to install (emerge) the latest
3.10.X series of sys-kernel/gentoo-sources as a slot, in parallel with
the latest gentoo-sources?

Currently, that would be version 3.10.28.
I know I can specify it like so,
emerge =sys-kernel/gentoo-sources-3.10.28

but then it would not get "auto-updated" when a newer version of that
series (for example 3.10.29) becomes available in portage.

Re: [gentoo-user] emerge latest in a certain version series of a package

[Andrew Tselischev]

On Tue, Jan 28, 2014 at 09:29:21PM +0200, Thanasis wrote:
> Is there a way to specify that I want to install (emerge) the latest
> 3.10.X series of sys-kernel/gentoo-sources as a slot, in parallel with
> the latest gentoo-sources?
> 
> Currently, that would be version 3.10.28.
> I know I can specify it like so,
> emerge =sys-kernel/gentoo-sources-3.10.28
> 
> but then it would not get "auto-updated" when a newer version of that
> series (for example 3.10.29) becomes available in portage.
> 

You could mask "newer" versions in package.mask like so:

>=sys-kernel/gentoo-sources-3.10.29*

Re: [gentoo-user] emerge latest in a certain version series of a package

[Thanasis]

on 01/28/2014 09:36 PM Andrew Tselischev wrote the following:
> On Tue, Jan 28, 2014 at 09:29:21PM +0200, Thanasis wrote:
>> Is there a way to specify that I want to install (emerge) the latest
>> 3.10.X series of sys-kernel/gentoo-sources as a slot, in parallel with
>> the latest gentoo-sources?
>>
>> Currently, that would be version 3.10.28.
>> I know I can specify it like so,
>> emerge =sys-kernel/gentoo-sources-3.10.28
>>
>> but then it would not get "auto-updated" when a newer version of that
>> series (for example 3.10.29) becomes available in portage.
>>
> 
> You could mask "newer" versions in package.mask like so:
> 
>> =sys-kernel/gentoo-sources-3.10.29*
> 
> 

Maybe I was not so clear, but my intent is *NOT* to mask any newer
versions, but have the sys-kernel/gentoo-sources-3.10.X get updated as a
slot, in parallel to latest sys-kernel/gentoo-sources, when I do a world
update like so:
emerge -DNu world

[gentoo-user] Re: emerge latest in a certain version series of a package

[eroen]

[-- Attachment #1.1: Type: text/plain, Size: 1419 bytes --]

On Tue, 28 Jan 2014 21:29:21 +0200, Thanasis <thanasis@asyr.hopto.org>
wrote:
>Is there a way to specify that I want to install (emerge) the latest
>3.10.X series of sys-kernel/gentoo-sources as a slot, in parallel with
>the latest gentoo-sources?
>
>Currently, that would be version 3.10.28.
>I know I can specify it like so,
>emerge =sys-kernel/gentoo-sources-3.10.28
>
>but then it would not get "auto-updated" when a newer version of that
>series (for example 3.10.29) becomes available in portage.

Afaik there is no configuration-only way to do this, but you can make
it happen by adding your own virtual ebuilds in a local overlay[1],
say virtual/thanasis-sources, then adding that to world.

You can make one ebuild for each kernel-series you want, each in its
own slot, using the =cat/pkg-3.10* syntax for RDEPEND. Find attached a
(barely tested) suggestion for
virtual/thanasis-sources/thanasis-sources-3.10.ebuild . One caveat,
=cat/pkg-3.10* also matches cat/pkg-3.107.1, which could become an
issue if you wanted, say, the 3.2 series.

After setting up an overlay and adding the ebuild, you can add it to
world with `emerge --select virtual/thanasis-sources:3.10`.

To add a different kernel series, you should only need to rename/copy
the ebuild in your overlay and add the new version/slot to world.


[1]: https://wiki.gentoo.org/wiki/Overlay/Local_overlay

-- 
eroen

[-- Attachment #1.2: thanasis-sources-3.10.ebuild --]
[-- Type: application/octet-stream, Size: 295 bytes --]

# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

EAPI=5

DESCRIPTION="Virtual for Linux kernel sources"
HOMEPAGE=""
SRC_URI=""

LICENSE=""
SLOT="${PV}"
KEYWORDS="~amd64"
IUSE=""

RDEPEND="=sys-kernel/gentoo-sources-${PV}*"

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] emerge latest in a certain version series of a package

[Alan McKinnon]

On 28/01/2014 22:04, Thanasis wrote:
> on 01/28/2014 09:36 PM Andrew Tselischev wrote the following:
>> On Tue, Jan 28, 2014 at 09:29:21PM +0200, Thanasis wrote:
>>> Is there a way to specify that I want to install (emerge) the latest
>>> 3.10.X series of sys-kernel/gentoo-sources as a slot, in parallel with
>>> the latest gentoo-sources?
>>>
>>> Currently, that would be version 3.10.28.
>>> I know I can specify it like so,
>>> emerge =sys-kernel/gentoo-sources-3.10.28
>>>
>>> but then it would not get "auto-updated" when a newer version of that
>>> series (for example 3.10.29) becomes available in portage.
>>>
>>
>> You could mask "newer" versions in package.mask like so:
>>
>>> =sys-kernel/gentoo-sources-3.10.29*
>>
>>
> 
> Maybe I was not so clear, but my intent is *NOT* to mask any newer
> versions, but have the sys-kernel/gentoo-sources-3.10.X get updated as a
> slot, in parallel to latest sys-kernel/gentoo-sources, when I do a world
> update like so:
> emerge -DNu world


that won't work as each kernel ebuild is in it's own unique slot
consisting of one and only one kernel version. I doubt the kernel team
are going to change that.

What you are asking is fundamentally not possible as slots are used in a
very incompatible way with your idea.

You will have to find and accept a workaround, such as masks.

But it's not really that big of a deal. Kernels ebuilds are sources,
they build no binaries. Having a version installed doesn't mean it runs,
it means you have the sources. All it consumes is disk space as they
don;tget updated

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] emerge latest in a certain version series of a package

[Alan McKinnon]

On 28/01/2014 22:04, Thanasis wrote:
> on 01/28/2014 09:36 PM Andrew Tselischev wrote the following:
>> On Tue, Jan 28, 2014 at 09:29:21PM +0200, Thanasis wrote:
>>> Is there a way to specify that I want to install (emerge) the latest
>>> 3.10.X series of sys-kernel/gentoo-sources as a slot, in parallel with
>>> the latest gentoo-sources?
>>>
>>> Currently, that would be version 3.10.28.
>>> I know I can specify it like so,
>>> emerge =sys-kernel/gentoo-sources-3.10.28
>>>
>>> but then it would not get "auto-updated" when a newer version of that
>>> series (for example 3.10.29) becomes available in portage.
>>>
>>
>> You could mask "newer" versions in package.mask like so:
>>
>>> =sys-kernel/gentoo-sources-3.10.29*
>>
>>
> 
> Maybe I was not so clear, but my intent is *NOT* to mask any newer
> versions, but have the sys-kernel/gentoo-sources-3.10.X get updated as a
> slot, in parallel to latest sys-kernel/gentoo-sources, when I do a world
> update like so:
> emerge -DNu world


that won't work as each kernel ebuild is in it's own unique slot
consisting of one and only one kernel version. I doubt the kernel team
are going to change that.

What you are asking is fundamentally not possible as slots are used in a
very incompatible way with your idea.

You will have to find and accept a workaround, such as masks.

But it's not really that big of a deal. Kernels ebuilds are sources,
they build no binaries. Having a version installed doesn't mean it runs,
it means you have the sources. All it consumes is disk space as they
don;tget updated

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] emerge latest in a certain version series of a package

[Alan McKinnon]

On 28/01/2014 22:04, Thanasis wrote:
> on 01/28/2014 09:36 PM Andrew Tselischev wrote the following:
>> On Tue, Jan 28, 2014 at 09:29:21PM +0200, Thanasis wrote:
>>> Is there a way to specify that I want to install (emerge) the latest
>>> 3.10.X series of sys-kernel/gentoo-sources as a slot, in parallel with
>>> the latest gentoo-sources?
>>>
>>> Currently, that would be version 3.10.28.
>>> I know I can specify it like so,
>>> emerge =sys-kernel/gentoo-sources-3.10.28
>>>
>>> but then it would not get "auto-updated" when a newer version of that
>>> series (for example 3.10.29) becomes available in portage.
>>>
>>
>> You could mask "newer" versions in package.mask like so:
>>
>>> =sys-kernel/gentoo-sources-3.10.29*
>>
>>
> 
> Maybe I was not so clear, but my intent is *NOT* to mask any newer
> versions, but have the sys-kernel/gentoo-sources-3.10.X get updated as a
> slot, in parallel to latest sys-kernel/gentoo-sources, when I do a world
> update like so:
> emerge -DNu world


that won't work as each kernel ebuild is in it's own unique slot
consisting of one and only one kernel version. I doubt the kernel team
are going to change that.

What you are asking is fundamentally not possible as slots are used in a
very incompatible way with your idea.

You will have to find and accept a workaround, such as masks.

But it's not really that big of a deal. Kernels ebuilds are sources,
they build no binaries. Having a version installed doesn't mean it runs,
it means you have the sources. All it consumes is disk space as they
don;tget updated

-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: emerge latest in a certain version series of a package

[James]

Alan McKinnon <alan.mckinnon <at> gmail.com> writes:


> >>> Is there a way to specify that I want to install (emerge) the latest
> >>> 3.10.X series of sys-kernel/gentoo-sources as a slot, in parallel with
> >>> the latest gentoo-sources?

> that won't work as each kernel ebuild is in it's own unique slot
> consisting of one and only one kernel version. I doubt the kernel team
> are going to change that.
> What you are asking is fundamentally not possible as slots are used in a
> very incompatible way with your idea.


Hmmmmm.
There might be a work around that suites your needs?



# emerge -pv =gentoo-sources-3.10.28

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  NS   ~] sys-kernel/gentoo-sources-3.10.28:3.10.28 [3.10.25:3.10.25,
3.13.0-r1:3.13.0-r1] USE="-build -deblob -experimental -symlink" 557 kB

Total: 1 package (1 in new slot), Size of downloads: 557 kB


Does that work for you?

(Note: I also have this in my package.keywords:
sys-kernel/gentoo-sources)

hth,
James



James

[gentoo-user] Re: emerge latest in a certain version series of a package

[James]

Thanasis <thanasis <at> asyr.hopto.org> writes:


> Currently, that would be version 3.10.28.
> I know I can specify it like so,
> emerge =sys-kernel/gentoo-sources-3.10.28

Opps, I did not read very deeply, still on first java_fix....

> but then it would not get "auto-updated" when a newer version of that
> series (for example 3.10.29) becomes available in portage.

Once the newer kernel series come out, the newer versions
of a series (usually) slow way down on being delivered.

Maybe a wildcard with the kernel series name in  your "world"
file might work.


At some point, the long kernel series revisions are usually
only about tweaking a few given features. If that is your
situation, dig into the kernel sources, read the docs and 
find the guy hacking on that option. Many will add additional
testers, if you know what your are doing.


Alternatively, run a cron job where you manually query
the gentoo-sources can parse out what you wnat by
kernel series number, and then mail that to yourself,
if it is all that important....


hth,
James

Re: [gentoo-user] Re: emerge latest in a certain version series of a package

[Alan McKinnon]

On 29/01/2014 15:23, James wrote:
> Alan McKinnon <alan.mckinnon <at> gmail.com> writes:
> 
> 
>>>>> Is there a way to specify that I want to install (emerge) the latest
>>>>> 3.10.X series of sys-kernel/gentoo-sources as a slot, in parallel with
>>>>> the latest gentoo-sources?
> 
>> that won't work as each kernel ebuild is in it's own unique slot
>> consisting of one and only one kernel version. I doubt the kernel team
>> are going to change that.
>> What you are asking is fundamentally not possible as slots are used in a
>> very incompatible way with your idea.
> 
> 
> Hmmmmm.
> There might be a work around that suites your needs?
> 
> 
> 
> # emerge -pv =gentoo-sources-3.10.28
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild  NS   ~] sys-kernel/gentoo-sources-3.10.28:3.10.28 [3.10.25:3.10.25,
> 3.13.0-r1:3.13.0-r1] USE="-build -deblob -experimental -symlink" 557 kB
> 
> Total: 1 package (1 in new slot), Size of downloads: 557 kB
> 
> 
> Does that work for you?
> 
> (Note: I also have this in my package.keywords:
> sys-kernel/gentoo-sources)

Ah but there's a catch to that.

3.10.28 is ~arch, so if you keyword it and don't mask later versions,
you get 3.13.0-r1 when updating world.

The OP wants automagic installation of sources when 3.10.28-r1 or
3.10.29 comes around, and portage don't do that.

For kernels, we're supposed to examine kernels closely, make a decision
and install sources for the very specific version of our choice. The
only automagic is for the very very latest of whatever arch we run




-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: emerge latest in a certain version series of a package

[Thanasis]

on 01/29/2014 03:23 PM James wrote the following:

> There might be a work around that suites your needs?
> 
> # emerge -pv =gentoo-sources-3.10.28
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild  NS   ~] sys-kernel/gentoo-sources-3.10.28:3.10.28 [3.10.25:3.10.25,
> 3.13.0-r1:3.13.0-r1] USE="-build -deblob -experimental -symlink" 557 kB
> 
> Total: 1 package (1 in new slot), Size of downloads: 557 kB
> 
> Does that work for you?

No, because as I said in a previous post, the matter is that when a
newer version 3.10.X is in the tree, and you do an update of the world
set, the newer kernel source of the 3.10.X series won't appear as an update.
You'll have to emerge it again "manually" and likewise "manually"
unmerge the older one.

Re: [gentoo-user] Re: emerge latest in a certain version series of a package

[Thanasis]

on 01/28/2014 10:12 PM eroen wrote the following:
> On Tue, 28 Jan 2014 21:29:21 +0200, Thanasis <thanasis@asyr.hopto.org>
> wrote:
>> Is there a way to specify that I want to install (emerge) the latest
>> 3.10.X series of sys-kernel/gentoo-sources as a slot, in parallel with
>> the latest gentoo-sources?
>>
>> Currently, that would be version 3.10.28.
>> I know I can specify it like so,
>> emerge =sys-kernel/gentoo-sources-3.10.28
>>
>> but then it would not get "auto-updated" when a newer version of that
>> series (for example 3.10.29) becomes available in portage.
> 
> Afaik there is no configuration-only way to do this, but you can make
> it happen by adding your own virtual ebuilds in a local overlay[1],
> say virtual/thanasis-sources, then adding that to world.
> 
> You can make one ebuild for each kernel-series you want, each in its
> own slot, using the =cat/pkg-3.10* syntax for RDEPEND. Find attached a
> (barely tested) suggestion for
> virtual/thanasis-sources/thanasis-sources-3.10.ebuild . 

Thanks eroen, I tested it and it looks like it works.

One caveat,
> =cat/pkg-3.10* also matches cat/pkg-3.107.1, 

I guess that kernel versions >= 3.100 are going to be in the tree, if
ever, probably in about a decade from now :P

> which could become an
> issue if you wanted, say, the 3.2 series.

Why would that be a problem?
In the ebuild, you specified the value
RDEPEND="=sys-kernel/gentoo-sources-${PV}*"

Re: [gentoo-user] Re: emerge latest in a certain version series of a package

[Thanasis]

on 01/29/2014 03:36 PM James wrote the following:

> Once the newer kernel series come out, the newer versions
> of a series (usually) slow way down on being delivered.

Not necessarily, if some devs are maintaining a series as "long term",
which, I think, is the case for the 3.10.X series (if I am not wrong).

> 
> Maybe a wildcard with the kernel series name in  your "world"
> file might work.

Yes, maybe.
And that's why am I asking.

> At some point, the long kernel series revisions are usually
> only about tweaking a few given features.

And bugs.

> If that is your
> situation, dig into the kernel sources, read the docs and 
> find the guy hacking on that option. Many will add additional
> testers, if you know what your are doing.

My situation, is not so complicated hopefully :P

> 
> 
> Alternatively, run a cron job where you manually query
> the gentoo-sources can parse out what you wnat by
> kernel series number, and then mail that to yourself,
> if it is all that important....

That would be another option, for another "manual" way.
Thanks for the idea though.

[gentoo-user] Re: emerge latest in a certain version series of a package

[eroen]

[-- Attachment #1: Type: text/plain, Size: 2325 bytes --]

On Wed, 29 Jan 2014 16:09:31 +0200, Thanasis <thanasis@asyr.hopto.org>
wrote:
> on 01/28/2014 10:12 PM eroen wrote the following:
> > On Tue, 28 Jan 2014 21:29:21 +0200, Thanasis
> > <thanasis@asyr.hopto.org> wrote:
> >> Is there a way to specify that I want to install (emerge) the
> >> latest 3.10.X series of sys-kernel/gentoo-sources as a slot, in
> >> parallel with the latest gentoo-sources?
> >>
> >> Currently, that would be version 3.10.28.
> >> I know I can specify it like so,
> >> emerge =sys-kernel/gentoo-sources-3.10.28
> >>
> >> but then it would not get "auto-updated" when a newer version of
> >> that series (for example 3.10.29) becomes available in portage.
> > 
> > Afaik there is no configuration-only way to do this, but you can
> > make it happen by adding your own virtual ebuilds in a local
> > overlay[1], say virtual/thanasis-sources, then adding that to world.
> > 
> > You can make one ebuild for each kernel-series you want, each in its
> > own slot, using the =cat/pkg-3.10* syntax for RDEPEND. Find
> > attached a (barely tested) suggestion for
> > virtual/thanasis-sources/thanasis-sources-3.10.ebuild . 
> 
> Thanks eroen, I tested it and it looks like it works.
> 
> One caveat,
> > =cat/pkg-3.10* also matches cat/pkg-3.107.1, 
> 
> I guess that kernel versions >= 3.100 are going to be in the tree, if
> ever, probably in about a decade from now :P
> 
> > which could become an
> > issue if you wanted, say, the 3.2 series.
> 
> Why would that be a problem?
> In the ebuild, you specified the value
> RDEPEND="=sys-kernel/gentoo-sources-${PV}*"

I think you got it, but then I confused you with a poorly chosen
example. The problem I referred to; if you try this exact method to
follow the 3.2.x kernels, you will switch to 3.20.0 when that comes
around. Similarly, it does not currently work with 3.1.x, and could
eventually (in a very long time, like you commented :P ) break for
other versions.

It would be nice to have a better way to accomplish this, perhaps
with some sort of world file variant supporting version ranges. That
could also be more intuitive and less prone to unintended consequences
(especially in the face of SLOTs) than package.mask-ing newer versions
to keep an old version of something around.

-- 
eroen

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-user] Re: emerge latest in a certain version series of a package

[James]

Thanasis <thanasis <at> asyr.hopto.org> writes:


> No, because as I said in a previous post, the matter is that when a
> newer version 3.10.X is in the tree, and you do an update of the world
> set, the newer kernel source of the 3.10.X series won't appear as an update.
> You'll have to emerge it again "manually" and likewise "manually"
> unmerge the older one.


Manual control/determination of kernels may appear overtly
clumsy, but it is far better to expend a bit of extra time, manually,
than in  panic mode; which is why I think you see a lack
of feature rich granularity in gentoo related to  kernels, imho.


James

[gentoo-user] Re: emerge latest in a certain version series of a package

[James]

Thanasis <thanasis <at> asyr.hopto.org> writes:


> on 01/29/2014 03:36 PM James wrote the following:

> > Once the newer kernel series come out, the newer versions
> > of a series (usually) slow way down on being delivered.
> Not necessarily, if some devs are maintaining a series as "long term",
> which, I think, is the case for the 3.10.X series (if I am not wrong).

Long term kernel series usually have one key guy (Cox historically) versus
thousands of devs work on things for new/latest/upcoming kernel releases. I
am a big fan of Alan Cox, as many of us are, and he is quite prolific
to be sure, but what you are saying, makes you appear, ignorant
of kernel development processes. I only use Alan Cox, as an example;
I have no idea who the long-term kernel maintainer is now, but
historically it's been somebody with a vested interest, or
some poor-unappreciated sap....imho.

The purpose of the long-term maintained kernels is in-fact and indeed,
so that folks do not have to change kernels often. Those features that
are fixed in a kernel series, are also "pulled-forward" into
the newer kernels series. FEW have valid reasons not to upgrade to
the newer series of stable kernels. It mu

Sometimes folks have to stay with a kernel series, because a vendor
binary patch forces them into this situation. In that case, the
vendor supplied patch might not even work (compile) with newer kernels
in a particular series. Commercial vendor support of a binary
wedged into a linux kernel, is fraught with all sorts of issues
quite often. Staying within a given kernel series is easier (mostly)
for companies to maintain a binary patch, with a poorly qualified
(learning?) noob kernel hacker, imho.....


If you want further help, you have to precisely define "why"
you need to stay in a particular kernel series, but yet
you need to be notified, immediately, without expending
some extra effort yourself?  You seem to be in a place (a want meerely?)
that the good-conservative folks associated with kernel responsibility,
do not provide for, because not many people have a valid reason
for such?


> > Maybe a wildcard with the kernel series name in  your "world"
> > file might work.
> Yes, maybe.
> And that's why am I asking.

> > At some point, the long kernel series revisions are usually
> > only about tweaking a few given features.

> And bugs.

(um "tweaks are another way of saying bug/feature fix/stabilization).


> My situation, is not so complicated hopefully :P

Do tell the specifics.... As some who has files of thousands of kernel
build notes and goes back into kernel sources, as far back as 2.0
series, mostly for embedded reasons:

Dude, I'm scratching my head, wondering whats up with your need.......


James

Re: [gentoo-user] Re: emerge latest in a certain version series of a package

[Thanasis]

on 01/29/2014 05:59 PM James wrote the following:

>>> Once the newer kernel series come out, the newer versions
>>> of a series (usually) slow way down on being delivered.
>> Not necessarily, if some devs are maintaining a series as "long term",
>> which, I think, is the case for the 3.10.X series (if I am not wrong).
> 
> Long term kernel series usually have one key guy (Cox historically) versus
> thousands of devs work on things for new/latest/upcoming kernel releases. I
> am a big fan of Alan Cox, as many of us are, and he is quite prolific
> to be sure, but what you are saying, makes you appear, ignorant
> of kernel development processes. 

I know I am mostly ignorant of kernel development processes.

> I only use Alan Cox, as an example;
> I have no idea who the long-term kernel maintainer is now, but
> historically it's been somebody with a vested interest, or
> some poor-unappreciated sap....imho.

Googling about kernel maintainer for long term 3.10, I found the
following page:
http://kroah.com/log/blog/2013/08/04/longterm-kernel-3-dot-10/
Would he (Greg) be the one?

> 
> The purpose of the long-term maintained kernels is in-fact and indeed,
> so that folks do not have to change kernels often.

Yea, maybe, but not my case though (see below).

> Those features that
> are fixed in a kernel series, are also "pulled-forward" into
> the newer kernels series. FEW have valid reasons not to upgrade to
> the newer series of stable kernels.

Right, unless ...

> 
> Sometimes folks have to stay with a kernel series, because a vendor
> binary patch forces them into this situation.

That's my case, ie Nvidia drivers for a relatively old hardware (AGP
Graphics).

> In that case, the
> vendor supplied patch might not even work (compile) with newer kernels
> in a particular series. Commercial vendor support of a binary
> wedged into a linux kernel, is fraught with all sorts of issues
> quite often. Staying within a given kernel series is easier (mostly)
> for companies to maintain a binary patch, with a poorly qualified
> (learning?) noob kernel hacker, imho.....

Bingo :)

> 
> If you want further help, you have to precisely define "why"
> you need to stay in a particular kernel series, but yet
> you need to be notified, immediately,

Well, I didn't say or mean "immediately", but, you know...make our time
easier... maybe invest it better...

> without expending some extra effort yourself? 
<snip>
> 
>> My situation, is not so complicated hopefully :P
> 
> Do tell the specifics.. I'm scratching my head, wondering whats up with your need.......

Nothing special. I am merely a home user, maintaining a few PCs. That's all.

Thanks James :)

Re: [gentoo-user] Re: emerge latest in a certain version series of a package

[Alan McKinnon]

On 29/01/2014 17:35, James wrote:
> Thanasis <thanasis <at> asyr.hopto.org> writes:
> 
> 
>> No, because as I said in a previous post, the matter is that when a
>> newer version 3.10.X is in the tree, and you do an update of the world
>> set, the newer kernel source of the 3.10.X series won't appear as an update.
>> You'll have to emerge it again "manually" and likewise "manually"
>> unmerge the older one.
> 
> 
> Manual control/determination of kernels may appear overtly
> clumsy, but it is far better to expend a bit of extra time, manually,
> than in  panic mode; which is why I think you see a lack
> of feature rich granularity in gentoo related to  kernels, imho.


Plus, the target market for Gentoo is folks who know how kernels work,
know what they want and know how to enable it without hand-holding.

If the target market doesn't know how to do this, they almost always
have the skills *and desire* to learn it, and usually do so very rapidly.

Add it all up with what you said and you get a complete explanation for
why gentoo-sources works like it does.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: emerge latest in a certain version series of a package

[Alan McKinnon]

On 29/01/2014 21:37, Thanasis wrote:
>> I only use Alan Cox, as an example;
>> > I have no idea who the long-term kernel maintainer is now, but
>> > historically it's been somebody with a vested interest, or
>> > some poor-unappreciated sap....imho.
> Googling about kernel maintainer for long term 3.10, I found the
> following page:
> http://kroah.com/log/blog/2013/08/04/longterm-kernel-3-dot-10/
> Would he (Greg) be the one?
> 


That's the one, he goes by the friendly name of gregkh.

Greg is something of a modern miracle, every time I try add up how many
kernel subsystems he maintains I get a number bigger than the number of
subsystems in the kernel....

go figure :-)

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: emerge latest in a certain version series of a package

[Thanasis]

on 01/29/2014 11:41 PM Alan McKinnon wrote the following:
> On 29/01/2014 17:35, James wrote:
>> Thanasis <thanasis <at> asyr.hopto.org> writes:
>>
>>
>>> No, because as I said in a previous post, the matter is that when a
>>> newer version 3.10.X is in the tree, and you do an update of the world
>>> set, the newer kernel source of the 3.10.X series won't appear as an update.
>>> You'll have to emerge it again "manually" and likewise "manually"
>>> unmerge the older one.
>>
>>
>> Manual control/determination of kernels may appear overtly
>> clumsy, but it is far better to expend a bit of extra time, manually,
>> than in  panic mode; which is why I think you see a lack
>> of feature rich granularity in gentoo related to  kernels, imho.
> 
> 
> Plus, the target market for Gentoo is folks who know how kernels work,
> know what they want and know how to enable it without hand-holding.
> 
> If the target market doesn't know how to do this, they almost always
> have the skills *and desire* to learn it, and usually do so very rapidly.
> 
> Add it all up with what you said and you get a complete explanation for
> why gentoo-sources works like it does.
> 

Yea, but I think, this is the case for *all* packages, not only kernel
sources, at least until now, isn't it?

Re: [gentoo-user] Re: emerge latest in a certain version series of a package

[Alan McKinnon]

On 30/01/2014 00:14, Thanasis wrote:
> on 01/29/2014 11:41 PM Alan McKinnon wrote the following:
>> On 29/01/2014 17:35, James wrote:
>>> Thanasis <thanasis <at> asyr.hopto.org> writes:
>>>
>>>
>>>> No, because as I said in a previous post, the matter is that when a
>>>> newer version 3.10.X is in the tree, and you do an update of the world
>>>> set, the newer kernel source of the 3.10.X series won't appear as an update.
>>>> You'll have to emerge it again "manually" and likewise "manually"
>>>> unmerge the older one.
>>>
>>>
>>> Manual control/determination of kernels may appear overtly
>>> clumsy, but it is far better to expend a bit of extra time, manually,
>>> than in  panic mode; which is why I think you see a lack
>>> of feature rich granularity in gentoo related to  kernels, imho.
>>
>>
>> Plus, the target market for Gentoo is folks who know how kernels work,
>> know what they want and know how to enable it without hand-holding.
>>
>> If the target market doesn't know how to do this, they almost always
>> have the skills *and desire* to learn it, and usually do so very rapidly.
>>
>> Add it all up with what you said and you get a complete explanation for
>> why gentoo-sources works like it does.
>>
> 
> Yea, but I think, this is the case for *all* packages, not only kernel
> sources, at least until now, isn't it?

No, not at all.

Kernels are different and portage treats them very differently.

Everything else gets sane defaults that you can tweak if you want to, or
leave as-is if you don't. With kernels, you do not have this choice -
you MUST tweak and customize it to get something that even runs at all.
OK, maybe bootloaders are also a bit special too..

There is no common basis of comparison between kernels and everything
else, that is how different they are. Sort of like saying rabbits work
like horses because they both have 4 legs. Yes, the bit about legs is
true but it also completely misses the point - there's no realistic
situation in everyday life where a rabbit works like a horse.

You are just going to have to face it - kernels are special. You either
deal with them The Gentoo Way, or run Ubuntu. Even genkernel doesn't
change this - all genkernel does is defer that same action onto someone
else, but the actions remain the same.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: emerge latest in a certain version series of a package

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 414 bytes --]

On Wednesday 29 Jan 2014 19:37:39 Thanasis wrote:
> > Sometimes folks have to stay with a kernel series, because a vendor
> > binary patch forces them into this situation.
> 
> That's my case, ie Nvidia drivers for a relatively old hardware (AGP
> Graphics).

Wouldn't nouveau drivers overcome this problem, or is some other reason 
keeping you with the proprietary NVidia drivers?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Re: emerge latest in a certain version series of a package

[Thanasis]

on 01/30/2014 08:30 AM Mick wrote the following:
> On Wednesday 29 Jan 2014 19:37:39 Thanasis wrote:
>>> Sometimes folks have to stay with a kernel series, because a vendor
>>> binary patch forces them into this situation.
>>
>> That's my case, ie Nvidia drivers for a relatively old hardware (AGP
>> Graphics).
> 
> Wouldn't nouveau drivers overcome this problem, or is some other reason 
> keeping you with the proprietary NVidia drivers?
> 
In 3D performance, the "nouveau" driver is my 2nd option.

Re: [gentoo-user] Re: emerge latest in a certain version series of a package

[Thanasis]

on 01/30/2014 12:50 AM Alan McKinnon wrote the following:
>> On 30/01/2014 00:14, Thanasis wrote:
>> Yea, but I think, this is the case for *all* packages, not only kernel
>> sources, at least until now, isn't it?
> 
> No, not at all.
> 
> Kernels are different and portage treats them very differently.
> 
> Everything else gets sane defaults that you can tweak if you want to, or
> leave as-is if you don't. With kernels, you do not have this choice -
> you MUST tweak and customize it to get something that even runs at all.
> OK, maybe bootloaders are also a bit special too..
> 
> There is no common basis of comparison between kernels and everything
> else, that is how different they are. Sort of like saying rabbits work
> like horses because they both have 4 legs. Yes, the bit about legs is
> true but it also completely misses the point - there's no realistic
> situation in everyday life where a rabbit works like a horse.
> 
> You are just going to have to face it - kernels are special. You either
> deal with them The Gentoo Way, or run Ubuntu. Even genkernel doesn't
> change this - all genkernel does is defer that same action onto someone
> else, but the actions remain the same.
> 

You are right, and I am not arguing about that. Of course kernels *are*
and have *always* been treated differently, than other packages.
All I wanted to say is, that even for other SLOTed packages, there is no
option in general (except for the special cases where VARIABLES are
assigned values in make.conf) for the user to choose to "follow" a
number of specific "subseries" of versions of a package.

Re: [gentoo-user] Re: emerge latest in a certain version series of a package

[Alan McKinnon]

On 30/01/2014 11:54, Thanasis wrote:
> on 01/30/2014 12:50 AM Alan McKinnon wrote the following:
>>> On 30/01/2014 00:14, Thanasis wrote:
>>> Yea, but I think, this is the case for *all* packages, not only kernel
>>> sources, at least until now, isn't it?
>>
>> No, not at all.
>>
>> Kernels are different and portage treats them very differently.
>>
>> Everything else gets sane defaults that you can tweak if you want to, or
>> leave as-is if you don't. With kernels, you do not have this choice -
>> you MUST tweak and customize it to get something that even runs at all.
>> OK, maybe bootloaders are also a bit special too..
>>
>> There is no common basis of comparison between kernels and everything
>> else, that is how different they are. Sort of like saying rabbits work
>> like horses because they both have 4 legs. Yes, the bit about legs is
>> true but it also completely misses the point - there's no realistic
>> situation in everyday life where a rabbit works like a horse.
>>
>> You are just going to have to face it - kernels are special. You either
>> deal with them The Gentoo Way, or run Ubuntu. Even genkernel doesn't
>> change this - all genkernel does is defer that same action onto someone
>> else, but the actions remain the same.
>>
> 
> You are right, and I am not arguing about that. Of course kernels *are*
> and have *always* been treated differently, than other packages.
> All I wanted to say is, that even for other SLOTed packages, there is no
> option in general (except for the special cases where VARIABLES are
> assigned values in make.conf) for the user to choose to "follow" a
> number of specific "subseries" of versions of a package.


Yes, I see what you mean. Portage restricts you to $arch and the SLOTs,
there's no mechanism whereby the user can easily pin down the exact
ranges or versions they want to have.

Your only option is to eternally fiddle with keywords and masks, but
this is a high maintenance route. You also have to keep checking that
your masks match what is in portage today. For most folks, that is much
more trouble than it's worth.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: emerge latest in a certain version series of a package

[James]

Thanasis <thanasis <at> asyr.hopto.org> writes:


> That's my case, ie Nvidia drivers for a relatively old hardware (AGP
> Graphics).

> Nothing special. I am merely a home user, maintaining a few PCs. That's all.

Nividia is a *VENDOR* that chooses not to provide information so 
drivers can be properly maintained, historically. ATI (AMD now) is a vendor
who provides information so drivers can be maintained, even optimized, into
perpetuity.

Maybe you chose unwisely?............(get ATI next time) unless
you have a valid reason for choosing a "prick" as your vendor?

As part of the open source community, I would think you have a 
repsonsibility to *reward those vendors that work generously with the 
greater open source community* ?

caveat emptor!

PS, if you card is very old, you can probably trade it for a
similar ATI card, imho. I do not waiste my time on nvidia*.


hth,
James

Re: [gentoo-user] Re: emerge latest in a certain version series of a package

[Alan McKinnon]

On 30/01/2014 17:25, James wrote:
> As part of the open source community, I would think you have a 
> repsonsibility to *reward those vendors that work generously with the 
> greater open source community* ?


No, not actually. The only responsibility he has is to do whatever he
feels like doing.

It is nice to favour vendors who work with us but no-one is obligated to
do so; trying to so is enforcing your moral code on another. That other
is free to entirely reject your moral code at will.

I get what you are saying but your statement is more accurate if you
omit or change the word "responsibility". It does not belong.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: emerge latest in a certain version series of a package

[Peter Humphrey]

On Thursday 30 Jan 2014 15:25:47 James wrote:

> Nividia is a *VENDOR* that chooses not to provide information so
> drivers can be properly maintained, historically. ATI (AMD now) is a vendor
> who provides information so drivers can be maintained, even optimized, into
> perpetuity.
> 
> Maybe you chose unwisely?............(get ATI next time) unless
> you have a valid reason for choosing a "prick" as your vendor?

I've used nVidia cards for many years. When I bought my first one (maybe 20 
years ago) ATI support in Linux was woeful, and the doggerel had it that the 
hardware was less competent too, so I chose nVidia.

Since then I've seen more cries for help on this list from ATI owners than 
nVidia, so it's not clear to me which is the better choice these days. Since I 
don't do bigotry my choice is on technical grounds, and I don't need hardware 
3D acceleration. So the jury's still out as far as I'm concerned.

Well, maybe CUDA might ramp up my contribution rate to BOINC projects a bit. 
Again, no obvious winner.

-- 
Regards
Peter

[gentoo-user] Re: emerge latest in a certain version series of a package

[James]

Peter Humphrey <peter <at> prh.myzen.co.uk> writes:


> > Maybe you chose unwisely?............(get ATI next time) unless

> 
> I've used nVidia cards for many years. When I bought my first one 
> (maybe 20  years ago) ATI support in Linux was woeful, and the doggerel  
> had it that the hardware was less competent too, so I chose nVidia.
> 
> Since then I've seen more cries for help on this list from ATI 
> owners than nVidia, so it's not clear to me which is the better choice  
> these days. > Since I don't do bigotry my choice is on technical grounds,
> and I don't > need hardware 3D acceleration. So the jury's still out as  
> far as I'm concerned.  Well, maybe CUDA might ramp up my contribution  
> rate to BOINC projects a bit.  Again, no obvious winner.

I agree with all you have said. However Nvidia's policies, not their
hardware, is the problem, hence the degraded comment on their reputation.
A company may struggle with the latest, robust hardware, but they
do not have to behave as "jerks". Nvidia's lack of copperation with
their old hardware, puts them in the "jerks" column in my mindset.
Even cisco provides full and complete sources, (from russia with love!).

The person is using old hardware, and for a very long time, ATI has
been the better choice for folks using old (video) hardware. He's not
pushing the  limits of performance; he just wants (needs?) a video card with
an open source solution.  I like to (stongly) suggest to folks to
use their "checkbook" to influence the behavior of vendors, ymmv.

Folks with low_dollars are almost aways better off with ATI, particualar
if they intend to run 'vintage video hardware', imho.


peace and good hunting,
James 

Re: [gentoo-user] Re: emerge latest in a certain version series of a package

[Thanasis]

on 01/30/2014 11:04 PM James wrote the following:
> Peter Humphrey <peter <at> prh.myzen.co.uk> writes:
> 
> 
>>> Maybe you chose unwisely?............(get ATI next time) unless
> 
>>
>> I've used nVidia cards for many years. When I bought my first one 
>> (maybe 20  years ago) ATI support in Linux was woeful, and the doggerel  
>> had it that the hardware was less competent too, so I chose nVidia.
>>
>> Since then I've seen more cries for help on this list from ATI 
>> owners than nVidia, so it's not clear to me which is the better choice  
>> these days. > Since I don't do bigotry my choice is on technical grounds,
>> and I don't > need hardware 3D acceleration. So the jury's still out as  
>> far as I'm concerned.  Well, maybe CUDA might ramp up my contribution  
>> rate to BOINC projects a bit.  Again, no obvious winner.
> 
> I agree with all you have said. However Nvidia's policies, not their
> hardware, is the problem, hence the degraded comment on their reputation.
> A company may struggle with the latest, robust hardware, but they
> do not have to behave as "jerks". Nvidia's lack of copperation with
> their old hardware, puts them in the "jerks" column in my mindset.
> Even cisco provides full and complete sources, (from russia with love!).
> 
> The person is using old hardware, and for a very long time, ATI has
> been the better choice for folks using old (video) hardware. He's not
> pushing the  limits of performance; he just wants (needs?) a video card with
> an open source solution.  I like to (stongly) suggest to folks to
> use their "checkbook" to influence the behavior of vendors, ymmv.
> 
> Folks with low_dollars are almost aways better off with ATI, particualar
> if they intend to run 'vintage video hardware', imho.
> 

James, I agree with you in general about supporting "open source
friendly vendors", but in this case, I would agree with Peter, because I
find that Nvidia although not so "open" as ATI, has been better
supporting (quicker to release drivers) for its newer cards than ATI does.

On the other hand, the old system I was talking about, is an Athlon 754
socket, with an NVIDIA G71 [GeForce 7800 GS] (rev a2) card.
I believe this card can use up the system's AGP bus (and the CPU) to its
limits, so I don't feel I should bother to change the card to an ATI
one, since I wouldn't gain any performance, except perhaps, for a
"radeon" driver in the kernel, which I doubt would perform as well as
the Nvidia's one.

Anyway, this Nvidia-vs-ATI discussion is going OT in the current thread.
And I think that we can close the current thread here.
Thanks to all for your help :)

Re: [gentoo-user] emerge latest in a certain version series of a package

[Khumba]

On Tue, 28 Jan 2014 21:29:21 +0200
Thanasis <thanasis@asyr.hopto.org> wrote:

> Is there a way to specify that I want to install (emerge) the latest
> 3.10.X series of sys-kernel/gentoo-sources as a slot, in parallel with
> the latest gentoo-sources?
> 
> Currently, that would be version 3.10.28.
> I know I can specify it like so,
> emerge =sys-kernel/gentoo-sources-3.10.28
> 
> but then it would not get "auto-updated" when a newer version of that
> series (for example 3.10.29) becomes available in portage.

I don't have Gentoo in front of me so I can't verify this now, but I
thought it worked to put the following in your world file:

    <sys-kernel/gentoo-sources-3.11

Of course if all 3.10 kernels are removed from the tree then this will
pull in a wrong kernel, but I *think* that's valid world file
syntax...

Cheers,
Khumba

Re: [gentoo-user] emerge latest in a certain version series of a package

[Khumba]

On Fri, 31 Jan 2014 08:35:22 -0800
Khumba <bog@khumba.net> wrote:

> On Tue, 28 Jan 2014 21:29:21 +0200
> Thanasis <thanasis@asyr.hopto.org> wrote:
> 
> > Is there a way to specify that I want to install (emerge) the latest
> > 3.10.X series of sys-kernel/gentoo-sources as a slot, in parallel with
> > the latest gentoo-sources?
> > 
> > Currently, that would be version 3.10.28.
> > I know I can specify it like so,
> > emerge =sys-kernel/gentoo-sources-3.10.28
> > 
> > but then it would not get "auto-updated" when a newer version of that
> > series (for example 3.10.29) becomes available in portage.
> 
> I don't have Gentoo in front of me so I can't verify this now, but I
> thought it worked to put the following in your world file:
> 
>     <sys-kernel/gentoo-sources-3.11
> 
> Of course if all 3.10 kernels are removed from the tree then this will
> pull in a wrong kernel, but I *think* that's valid world file
> syntax...

Ah right, this will pull in _alpha up to _rc versions of 3.11, but as
long as the kernel ebuilds aren't using those versions.  Or maybe
<sys-kernel/gentoo-sources-3.11_alpha?

- Khumba

Re: [gentoo-user] emerge latest in a certain version series of a package

[Thanasis]

on 01/31/2014 06:35 PM Khumba wrote the following:
> On Tue, 28 Jan 2014 21:29:21 +0200
> Thanasis <thanasis@asyr.hopto.org> wrote:
> 
>> Is there a way to specify that I want to install (emerge) the latest
>> 3.10.X series of sys-kernel/gentoo-sources as a slot, in parallel with
>> the latest gentoo-sources?
>>
>> Currently, that would be version 3.10.28.
>> I know I can specify it like so,
>> emerge =sys-kernel/gentoo-sources-3.10.28
>>
>> but then it would not get "auto-updated" when a newer version of that
>> series (for example 3.10.29) becomes available in portage.
> 
> I don't have Gentoo in front of me so I can't verify this now, but I
> thought it worked to put the following in your world file:
> 
>     <sys-kernel/gentoo-sources-3.11
> 
> Of course if all 3.10 kernels are removed from the tree then this will
> pull in a wrong kernel, but I *think* that's valid world file
> syntax...
> 

I don't know if what you're suggesting would work, yet if you noticed as
I wrote in the first place, I would also like to pull in the *latest*
gentoo-sources, *independently* of any specific series/subseries.
Do you think it would work?

Re: [gentoo-user] emerge latest in a certain version series of a package

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 948 bytes --]

On Fri, 31 Jan 2014 19:41:09 +0200, Thanasis wrote:

> >     <sys-kernel/gentoo-sources-3.11
> > 
> > Of course if all 3.10 kernels are removed from the tree then this will
> > pull in a wrong kernel, but I *think* that's valid world file
> > syntax...
> >   
> 
> I don't know if what you're suggesting would work, yet if you noticed as
> I wrote in the first place, I would also like to pull in the *latest*
> gentoo-sources, *independently* of any specific series/subseries.
> Do you think it would work?

I think it would, I used to have a general gentoo-sources plus specific
versions in world before it was possible to use sets to stop older
kernels being depcleaned. If you have the above line plus an unversioned
atom, I think you should get something close to what you want.

Of course, there's an easy way to tell if it would work...


-- 
Neil Bothwick

We are from the planet Taglinis. Take us to your reader!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] emerge latest in a certain version series of a package

[Khumba]

On Fri, 31 Jan 2014 22:47:31 +0000
Neil Bothwick <neil@digimed.co.uk> wrote:

> On Fri, 31 Jan 2014 19:41:09 +0200, Thanasis wrote:
> 
> > >     <sys-kernel/gentoo-sources-3.11
> > > 
> > > Of course if all 3.10 kernels are removed from the tree then this will
> > > pull in a wrong kernel, but I *think* that's valid world file
> > > syntax...
> > >   
> > 
> > I don't know if what you're suggesting would work, yet if you noticed as
> > I wrote in the first place, I would also like to pull in the *latest*
> > gentoo-sources, *independently* of any specific series/subseries.
> > Do you think it would work?
> 
> I think it would, I used to have a general gentoo-sources plus specific
> versions in world before it was possible to use sets to stop older
> kernels being depcleaned. If you have the above line plus an unversioned
> atom, I think you should get something close to what you want.
> 
> Of course, there's an easy way to tell if it would work...

Yeah sorry, I should have been clearer, I meant with two separate atoms.

- Khumba

Re: [gentoo-user] emerge latest in a certain version series of a package [SOLVED]

[Thanasis]

[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]

on 02/01/2014 12:47 AM Neil Bothwick wrote the following:

> 
> I think it would, I used to have a general gentoo-sources plus specific
> versions in world before it was possible to use sets to stop older
> kernels being depcleaned. If you have the above line plus an unversioned
> atom, I think you should get something close to what you want.
> 
> Of course, there's an easy way to tell if it would work...
> 
> 

Tried it and indeed it *worked*.

So, for the record, here are the two solutions, as suggested in this thread:

1) Proposed by eroen:

You can make it happen by adding your own virtual ebuilds in a local
overlay[1], say virtual/thanasis-sources, then adding that to world.

You can make one ebuild for each kernel-series you want, each in its
own slot, using the =cat/pkg-3.10* syntax for RDEPEND. Find attached a
(barely tested) suggestion for
virtual/thanasis-sources/thanasis-sources-3.10.ebuild .

After setting up an overlay and adding the ebuild, you can add it to
world with `emerge --select virtual/thanasis-sources:3.10`.

To add a different kernel series, you should only need to rename/copy
the ebuild in your overlay and add the new version/slot to world.

[1]: https://wiki.gentoo.org/wiki/Overlay/Local_overlay

2) Proposed by Khumba:

Put the following in your world file:
    <sys-kernel/gentoo-sources-3.11
    sys-kernel/gentoo-sources

*Thanks* to all for your help:)






[-- Attachment #2: thanasis-sources-3.10.ebuild --]
[-- Type: text/plain, Size: 295 bytes --]

# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

EAPI=5

DESCRIPTION="Virtual for Linux kernel sources"
HOMEPAGE=""
SRC_URI=""

LICENSE=""
SLOT="${PV}"
KEYWORDS="~amd64"
IUSE=""

RDEPEND="=sys-kernel/gentoo-sources-${PV}*"