Re: [gentoo-user] Re: emerge latest in a certain version series of a package
on 01/30/2014 11:04 PM James wrote the following: > Peter Humphrey 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 :)
[gentoo-user] Re: emerge latest in a certain version series of a package
Peter Humphrey 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
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
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
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.mckin...@gmail.com
[gentoo-user] Re: emerge latest in a certain version series of a package
Thanasis 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
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.mckin...@gmail.com
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
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
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
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
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 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.mckin...@gmail.com
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
on 01/29/2014 11:41 PM Alan McKinnon wrote the following: > On 29/01/2014 17:35, James wrote: >> Thanasis 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
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 sapimho. > 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.mckin...@gmail.com
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
On 29/01/2014 17:35, James wrote: > Thanasis 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.mckin...@gmail.com
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
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 sapimho. 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? > >> 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 :)
[gentoo-user] Re: emerge latest in a certain version series of a package
Thanasis 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 sapimho. 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
[gentoo-user] Re: emerge latest in a certain version series of a package
Thanasis 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
On Wed, 29 Jan 2014 16:09:31 +0200, Thanasis
wrote:
> on 01/28/2014 10:12 PM eroen wrote the following:
> > On Tue, 28 Jan 2014 21:29:21 +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.
> >
> > 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
signature.asc
Description: PGP signature
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
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.
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
on 01/28/2014 10:12 PM eroen wrote the following:
> On Tue, 28 Jan 2014 21:29:21 +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.
>
> 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
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
On 29/01/2014 15:23, James wrote: > Alan McKinnon 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. > > > Hm. > 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.mckin...@gmail.com
[gentoo-user] Re: emerge latest in a certain version series of a package
Thanasis 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
[gentoo-user] Re: emerge latest in a certain version series of a package
Alan McKinnon 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. Hm. 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
On Tue, 28 Jan 2014 21:29:21 +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. 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 thanasis-sources-3.10.ebuild Description: Binary data signature.asc Description: PGP signature
