[gentoo-user] using package.provided

[gentoo-user] using package.provided

[reader]

This section is snipped one of Allen M. posts on the monster gentoo
health thread (last paragraph is where my topic starts:
[...]
  Archive a portage tree by all means. But if an ebuild is removed that a 
  user want to keep, the solution is so simple it's amazing. Copy the 
  ebuild to /usr/local/portage in the correct directory structure. I 
  maintain my own enlightenment-17 ebuilds, so to start I did this:

  mkdir -p /usr/local/portage/x11-wm
  cp -ar /usr/portage/x11-wm/e /usr/local/portage/x11-wm

  Run emerge. Simple as that. You might need to add an entry to 
  package.mask so that portage won't use later versions in the main tree 
  but that's all part of normal gentoo usage anyway.
[...]

In the event user runs with ~ARCHITECTURE flag set then masking won't
do it... right?

So my understanding is that user needs to set something in:
  /etc/portage/profile/package.provided showing an equal or higher
version number than what is available in portage (masked or not).
(To maintain users own package)

Assuming I got this much right, is there a better way?

I ask because setting a higher version number might eventually need
bumping still higher... or if versioning changes somehow will `higher'
not be noticed.

Looking for a way not to have to check package.provided to make sure
versioning is still good.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] using package.provided

[Alan McKinnon]

On Thursday 21 December 2006 18:04, reader@newsguy.com wrote:

> In the event user runs with ~ARCHITECTURE flag set then masking won't
> do it... right?

Wrong.

Masking says what portage should include as installable. Look inside an 
ebuild and you will see lines like

KEYWORDS="~ppc sparc x86"

That means that this ebuild is OK for unstable ppc, sparc and x86. It's 
also OK for ~sparc and ~x86. So if you run ~arch then you can install 
any unstable package, and you can also install anything in 
package.keywords that's marked ~arch (or blank, as that's how that file 
works)

> So my understanding is that user needs to set something in:
>   /etc/portage/profile/package.provided showing an equal or higher
> version number than what is available in portage (masked or not).
> (To maintain users own package)

No, this is completely wrong. Go read the man page - man 5 ebuild

provided is for packages that you have already provided by other means 
that portage. Example - kernels. Some users like to do the kernel 
themselves without any help form portage. But portage insists on 
knowing about your kernel and will want to install one. So with 
package.provided you are essentially saying "Assume this package is 
already there and I have provided it. I'm the user - trust me"

> Assuming I got this much right, is there a better way?

Yes, do it the way portage is designed to work. With overlays (assuming 
we are still on-topic from my original post

> I ask because setting a higher version number might eventually need
> bumping still higher... or if versioning changes somehow will
> `higher' not be noticed.

If you want to maintain and use old package-1.0.0 by yourself, and there 
is already package-2.3 in the portage tree, then you need to mask out 
any version greater than your custom ebuild. So, you put this 
in /etc/portage/package.mask:

>package-1.0.0

Thus, everthing else in the tree is masked out and can't be used by 
portage. the only thing left is the ebuild in your overlay 
in /usr/local/portage

> Looking for a way not to have to check package.provided to make sure
> versioning is still good.

You need to learn more about portage. Read:

man portage
man 5 portage
man ebuild
man 5 ebuild

All your questions are answered in there.

alan


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] using package.provided

[Neil Bothwick]

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

On Thu, 21 Dec 2006 10:04:33 -0600, reader@newsguy.com wrote:

> [...]
>   Archive a portage tree by all means. But if an ebuild is removed that
> a user want to keep, the solution is so simple it's amazing. Copy the 
>   ebuild to /usr/local/portage in the correct directory structure. I 
>   maintain my own enlightenment-17 ebuilds, so to start I did this:
> 
>   mkdir -p /usr/local/portage/x11-wm
>   cp -ar /usr/portage/x11-wm/e /usr/local/portage/x11-wm
> 
>   Run emerge. Simple as that. You might need to add an entry to 
>   package.mask so that portage won't use later versions in the main
> tree but that's all part of normal gentoo usage anyway.
> [...]
> 
> In the event user runs with ~ARCHITECTURE flag set then masking won't
> do it... right?

Wrong. Package masking is independent of keyword masking. Adding an atom
to package.mask will mask all matching versions, no matter what their
keywords.

> So my understanding is that user needs to set something in:
>   /etc/portage/profile/package.provided showing an equal or higher
> version number than what is available in portage (masked or not).
> (To maintain users own package)

package.provided is intended for use when you install something without
portage - it's your way of telling portage the package is installed even
though it's not in the database.

> I ask because setting a higher version number might eventually need
> bumping still higher... or if versioning changes somehow will `higher'
> not be noticed.

If an installed package requires a higher version than you have
installed, then it needs it. Lying to portage about the version you have
installed won't fix that, it just delays the breakage until later.
Masking on the other had, produces a civilised error message telling you
that package A needs package B greater than version N, and that it is
masked.

> Looking for a way not to have to check package.provided to make sure
> versioning is still good.

While package.provided does have some genuine uses, one of its main
functions is to provide people who don't fully understand it with a simple
way of producing hard to diagnose system breakages :(


-- 
Neil Bothwick

WinErr 010: Reserved for future mistakes by our developers

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

[gentoo-user] Re: using package.provided

[reader]

Alan McKinnon <alan@linuxholdings.co.za> writes:

>> I ask because setting a higher version number might eventually need
>> bumping still higher... or if versioning changes somehow will
>> `higher' not be noticed.
>
> If you want to maintain and use old package-1.0.0 by yourself, and there 
> is already package-2.3 in the portage tree, then you need to mask out 
> any version greater than your custom ebuild. So, you put this 
> in /etc/portage/package.mask:

Thanks for the tips on other areas too, but the above tip clears up
something I've had wrong for some time.  

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: using package.provided

[reader]

Neil Bothwick <neil@digimed.co.uk> writes:

> While package.provided does have some genuine uses, one of its main
> functions is to provide people who don't fully understand it with a simple
> way of producing hard to diagnose system breakages :(

Very good.... Made my day.

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: using package.provided

[reader]

Alan McKinnon <alan@linuxholdings.co.za> writes:

> This section is snipped [from -sic]  one of Allen M. posts
                                              ^^^^^
Please excuse the misspelling

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] using package.provided

[Uwe Thiem]

On 21 December 2006 18:40, Neil Bothwick wrote:

> package.provided is intended for use when you install something without
> portage - it's your way of telling portage the package is installed even
> though it's not in the database.

What is that good for? Say I write my own app (like the one my signature 
refers to) and install it system-wide without creating an ebuild, what does 
it change if I put it into package.provided? I mean portage doesn't know 
anything about it either way.

Uwe

-- 
A fast and easy generator of fractals for KDE:
http://www.SysEx.com.na/iwy-1.0.tar.bz2
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] using package.provided

[Alan McKinnon]

On Thursday 21 December 2006 19:36, Uwe Thiem wrote:
> On 21 December 2006 18:40, Neil Bothwick wrote:
> > package.provided is intended for use when you install something
> > without portage - it's your way of telling portage the package is
> > installed even though it's not in the database.
>
> What is that good for? Say I write my own app (like the one my
> signature refers to) and install it system-wide without creating an
> ebuild, what does it change if I put it into package.provided? I mean
> portage doesn't know anything about it either way.

package.provided is not there for that purpose. It's there for cases 
when a package should be present but portage hasn't installed it (like 
highly custom kernels) and you don't intend for portage to ever install 
it either. But portage insists that a kernel must be present.

So you tell it that _you_ have provided one yourself.

It's all a bit of a hack and a dodge because 'emerge world' tends to 
obliterate your provideds anyway (according to some arcane man page 
somewhere....), and it seems to be very much an edge case for those 3 
people in the whole world that need/want it.

Myself, I have never used it. If it's not in portage, I write my own 
ebuild, or put it in /usr/local

alan

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] using package.provided

[Neil Bothwick]

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

On Thu, 21 Dec 2006 19:36:59 +0200, Uwe Thiem wrote:

> > package.provided is intended for use when you install something
> > without portage - it's your way of telling portage the package is
> > installed even though it's not in the database.  
> 
> What is that good for? Say I write my own app (like the one my
> signature refers to) and install it system-wide without creating an
> ebuild, what does it change if I put it into package.provided? I mean
> portage doesn't know anything about it either way.

It changes nothing in that case, but that's not what it is for.
package.provided is for use when a package is in portage but you have
chosen to install it independently. Say package A depends on package B,
but you don;t want package B installed through portage (maybe you want
the latest CVS version). Portage would then try to install the older
package B because it thinks it needs it to satisfy package A's
dependencies. All package.provided does is tell portage "you may not see
it in your database but cate-gory/packageb-x.y.z is installed".

package.provided is potentially dangerous because portage is now basing
its decisions on what you tell it is installed rather than what it knows
is installed, you are overriding the normal dependency checks. If package
A is incompatible with the later package B, portage won't know and
problems may surface later.


-- 
Neil Bothwick

Isn't 'Criminal Lawyer' rather redundant?

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

Re: [gentoo-user] using package.provided

[Uwe Thiem]

On 22 December 2006 09:03, Alan McKinnon wrote:

> package.provided is not there for that purpose. It's there for cases
> when a package should be present but portage hasn't installed it (like
> highly custom kernels) and you don't intend for portage to ever install
> it either. But portage insists that a kernel must be present.
>
> So you tell it that _you_ have provided one yourself.

Oh, I see. Thanks!

Uwe

-- 
A fast and easy generator of fractals for KDE:
http://www.SysEx.com.na/iwy-1.0.tar.bz2
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: using package.provided

[reader]

Alan McKinnon <alan@linuxholdings.co.za> writes:

> You need to learn more about portage. Read:
>
> man portage
> man 5 portage
> man ebuild
> man 5 ebuild

Now I have a better idea how things are meant to work... but if I want
to violate that... by that I mean ..not work on my own ebuild enough
to begin to understand how its done... not put in the time and effort
required to do my own ebuild.

I like to build my own emacs, I've used emacs since about 1996, Long
before I started with gentoo (about 2 yrs now ago).

I like where a default emacs build and install puts stuff, I like the
emacs maintainers ideas of preloaded stuff.  I don't want to find some
buried package conflict due to something gentoo devs think should be
preloaded or whatever.

I have a long list of special lisp packages in places I expect.
I update from cvs often.

In short I prefer not having to even think about all the above. 
I prefer the simplicity of hand installation and know exactly what to
expect.  

cd /usr/local/cvs/emacs and cvs update -Pd
./configure
make 
make install

All that said, what then would be the best way to let gentoo know I
have installed a very recent emacs and any dependancies gentoo may
need are available at /usr/local/share/emacs.

I've been doing it by putting this in
/etc/portage/profile/package.provided

  app-editors/emacs-cvs-24
  app-editors/emacs-24

(not sure if the double entry matters)

Is it correct that at least theoretically:
When emacs passes version 24 gentoo would then begin installing emacs
from portage?

Is that likely to fall victim to Neils humorous point about causing
hard to diagnose system problems?

Is there a better way to accomplish my goal?  The masking approach was
explained as being a way to continue to use OLDER packages which is
not the case here.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: using package.provided

[Neil Bothwick]

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

On Fri, 22 Dec 2006 11:05:40 -0600, reader@newsguy.com wrote:

> All that said, what then would be the best way to let gentoo know I
> have installed a very recent emacs and any dependancies gentoo may
> need are available at /usr/local/share/emacs.
> 
> I've been doing it by putting this in
> /etc/portage/profile/package.provided
> 
>   app-editors/emacs-cvs-24
>   app-editors/emacs-24

Yes, that's just the sort of situation package.provided is intended for.


-- 
Neil Bothwick

Shell to DOS... Shell to DOS... DOS, do you copy? Shell to DOS...

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

[gentoo-user] using package.provided

[Harry Putnam]

I'd like to stay on kernel-4.1.6, rather than keep installing the
newest version at each upgrade.

As I recall, and a quick look at `man portage', a file named
`package.provided' is meant for such things.

The syntax is not described in detail... I tried these:

  /etc/portage/package.provided

  >=sys-kernel/gentoo-sources-4.1.6

Still `emerge -vp gentoo-sources' indicates it will install the most
recent kernel.

then I noticed the portage man page, under `Format' does say:
"relational operators are not allowed"
So I dropped the `>=' part

  sys-kernel/gentoo-sources-4.1.6

Same result from `emerge -vp gentoo-sources' . . .

What am I forgetting?

Re: [gentoo-user] using package.provided

[Dale]

Harry Putnam wrote:
> I'd like to stay on kernel-4.1.6, rather than keep installing the
> newest version at each upgrade.
>
> As I recall, and a quick look at `man portage', a file named
> `package.provided' is meant for such things.
>
> The syntax is not described in detail... I tried these:
>
>   /etc/portage/package.provided
>
>   >=sys-kernel/gentoo-sources-4.1.6
>
> Still `emerge -vp gentoo-sources' indicates it will install the most
> recent kernel.
>
> then I noticed the portage man page, under `Format' does say:
> "relational operators are not allowed"
> So I dropped the `>=' part
>
>   sys-kernel/gentoo-sources-4.1.6
>
> Same result from `emerge -vp gentoo-sources' . . .
>
> What am I forgetting?
>
>
>


This is how I do this sort of thing.  I add the name and version to
package.mask which stops future updates/upgrades.  Example, for my
nvidia drivers, this is in package.mask.

>=x11-drivers/nvidia-drivers-341.0.0 

That tells portage that anything above that version is masked locally
and not to update it.  For what you want, this should work:

>sys-kernel/gentoo-sources-4.1.6

I removed the equal sign since you want to keep that version around but
nothing above it.  If portage doesn't like that, you may want to use the
next version up and have the ">=" in front.  According to what I have
here, it would be like this:

>=sys-kernel/gentoo-sources-4.1.12 

I actually don't show a 4.1.6 here right now.  Removed I guess but
likely still works.

That goes under /etc/portage/ by the way.  I think you know that already
but just in case.  I have those moments too.  ;-) 

That helps??

Dale

:-)  :-) 

Re: [gentoo-user] using package.provided

[Dale]

Dale wrote:
> Harry Putnam wrote:
>> I'd like to stay on kernel-4.1.6, rather than keep installing the
>> newest version at each upgrade.
>>
>> As I recall, and a quick look at `man portage', a file named
>> `package.provided' is meant for such things.
>>
>> The syntax is not described in detail... I tried these:
>>
>>   /etc/portage/package.provided
>>
>>   >=sys-kernel/gentoo-sources-4.1.6
>>
>> Still `emerge -vp gentoo-sources' indicates it will install the most
>> recent kernel.
>>
>> then I noticed the portage man page, under `Format' does say:
>> "relational operators are not allowed"
>> So I dropped the `>=' part
>>
>>   sys-kernel/gentoo-sources-4.1.6
>>
>> Same result from `emerge -vp gentoo-sources' . . .
>>
>> What am I forgetting?
>>
>>
>>
>
> This is how I do this sort of thing.  I add the name and version to
> package.mask which stops future updates/upgrades.  Example, for my
> nvidia drivers, this is in package.mask.
>
>> =x11-drivers/nvidia-drivers-341.0.0 
> That tells portage that anything above that version is masked locally
> and not to update it.  For what you want, this should work:
>
>> sys-kernel/gentoo-sources-4.1.6
> I removed the equal sign since you want to keep that version around but
> nothing above it.  If portage doesn't like that, you may want to use the
> next version up and have the ">=" in front.  According to what I have
> here, it would be like this:
>
>> =sys-kernel/gentoo-sources-4.1.12 
> I actually don't show a 4.1.6 here right now.  Removed I guess but
> likely still works.
>
> That goes under /etc/portage/ by the way.  I think you know that already
> but just in case.  I have those moments too.  ;-) 
>
> That helps??
>
> Dale
>
> :-)  :-) 
>
>

I was triple checking and realized something.  Some of the lines are not
correct.  It seems in my email software at least it puts a little line
in place of the >.  So, let me try this way.  


Nvidia is like this:  >=x11-drivers/nvidia-drivers-341.0.0

Your kernel line may work like this:  >sys-kernel/gentoo-sources-4.1.6

Or it may have to be like this if portage doesn't like the above: 
>=sys-kernel/gentoo-sources-4.1.12

Now, let's see if that displays correctly.  I won't know until I send it
and get it back. 

Dale

:-)  :-) 

Re: [gentoo-user] using package.provided

[Dale]

Dale wrote:
> Dale wrote:
>> Harry Putnam wrote:
>>> I'd like to stay on kernel-4.1.6, rather than keep installing the
>>> newest version at each upgrade.
>>>
>>> As I recall, and a quick look at `man portage', a file named
>>> `package.provided' is meant for such things.
>>>
>>> The syntax is not described in detail... I tried these:
>>>
>>>   /etc/portage/package.provided
>>>
>>>   >=sys-kernel/gentoo-sources-4.1.6
>>>
>>> Still `emerge -vp gentoo-sources' indicates it will install the most
>>> recent kernel.
>>>
>>> then I noticed the portage man page, under `Format' does say:
>>> "relational operators are not allowed"
>>> So I dropped the `>=' part
>>>
>>>   sys-kernel/gentoo-sources-4.1.6
>>>
>>> Same result from `emerge -vp gentoo-sources' . . .
>>>
>>> What am I forgetting?
>>>
>>>
>>>
>> This is how I do this sort of thing.  I add the name and version to
>> package.mask which stops future updates/upgrades.  Example, for my
>> nvidia drivers, this is in package.mask.
>>
>>> =x11-drivers/nvidia-drivers-341.0.0 
>> That tells portage that anything above that version is masked locally
>> and not to update it.  For what you want, this should work:
>>
>>> sys-kernel/gentoo-sources-4.1.6
>> I removed the equal sign since you want to keep that version around but
>> nothing above it.  If portage doesn't like that, you may want to use the
>> next version up and have the ">=" in front.  According to what I have
>> here, it would be like this:
>>
>>> =sys-kernel/gentoo-sources-4.1.12 
>> I actually don't show a 4.1.6 here right now.  Removed I guess but
>> likely still works.
>>
>> That goes under /etc/portage/ by the way.  I think you know that already
>> but just in case.  I have those moments too.  ;-) 
>>
>> That helps??
>>
>> Dale
>>
>> :-)  :-) 
>>
>>
> I was triple checking and realized something.  Some of the lines are not
> correct.  It seems in my email software at least it puts a little line
> in place of the >.  So, let me try this way.  
>
>
> Nvidia is like this:  >=x11-drivers/nvidia-drivers-341.0.0
>
> Your kernel line may work like this:  >sys-kernel/gentoo-sources-4.1.6
>
> Or it may have to be like this if portage doesn't like the above: 
>> =sys-kernel/gentoo-sources-4.1.12
> Now, let's see if that displays correctly.  I won't know until I send it
> and get it back. 
>
> Dale
>
> :-)  :-) 
>


Silly software.  That bottom line wraps here so it took it out like the
first email did.  So, if it is doing the same for you, that bottom line
needs a greater than sign in front of the category and package name. 
Let's see if it edits out the words "greater than sign" as well.  ROFL  
The biggest thing, I think you want to use package.mask anyway.  That
should help. 

Jeez.  Sometimes I want to take a hammer to a puter. 

Dale

:-)  :-)

Re: [gentoo-user] using package.provided

[Neil Bothwick]

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

On Wed, 24 Feb 2016 22:55:30 -0500, Harry Putnam wrote:

> I'd like to stay on kernel-4.1.6, rather than keep installing the
> newest version at each upgrade.
> 
> As I recall, and a quick look at `man portage', a file named
> `package.provided' is meant for such things.

No it's not. package.provided is for when you install a package from
outside of portage and want to let portage know it is installed.

> The syntax is not described in detail... I tried these:
> 
>   /etc/portage/package.provided

The file is /etc/portage/profile/package.provided
> 
>   >=sys-kernel/gentoo-sources-4.1.6  

and it only allows specific atoms, =cat/pkg

> Still `emerge -vp gentoo-sources' indicates it will install the most
> recent kernel.

You want to use /etc/portage/package.mask, with this entry

    >sys-kernel/gentoo-sources-4.1.6

One of the disadvantages of this is that when that particular version is
removed from the tree, portage will try to downgrade, because you has
blocked an upgrade. To avoid this, copy the ebuild to a local overlay so
it is always available.

You'll also miss out on any security updates etc, but I guess you have
already considered that.


-- 
Neil Bothwick

If Wile E. Coyote had enough money to buy all that ACME crap, why didn't
he just buy dinner?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] using package.provided

[covici]

Dale <rdalek1967@gmail.com> wrote:

> Harry Putnam wrote:
> > I'd like to stay on kernel-4.1.6, rather than keep installing the
> > newest version at each upgrade.
> >
> > As I recall, and a quick look at `man portage', a file named
> > `package.provided' is meant for such things.
> >
> > The syntax is not described in detail... I tried these:
> >
> >   /etc/portage/package.provided
> >
> >   >=sys-kernel/gentoo-sources-4.1.6
> >
> > Still `emerge -vp gentoo-sources' indicates it will install the most
> > recent kernel.
> >
> > then I noticed the portage man page, under `Format' does say:
> > "relational operators are not allowed"
> > So I dropped the `>=' part
> >
> >   sys-kernel/gentoo-sources-4.1.6
> >
> > Same result from `emerge -vp gentoo-sources' . . .
> >
> > What am I forgetting?
> >
> >
> >
> 
> 
> This is how I do this sort of thing.  I add the name and version to
> package.mask which stops future updates/upgrades.  Example, for my
> nvidia drivers, this is in package.mask.
> 
> >=x11-drivers/nvidia-drivers-341.0.0 
> 
> That tells portage that anything above that version is masked locally
> and not to update it.  For what you want, this should work:
> 
> >sys-kernel/gentoo-sources-4.1.6
> 
> I removed the equal sign since you want to keep that version around but
> nothing above it.  If portage doesn't like that, you may want to use the
> next version up and have the ">=" in front.  According to what I have
> here, it would be like this:
> 
> >=sys-kernel/gentoo-sources-4.1.12 
> 
> I actually don't show a 4.1.6 here right now.  Removed I guess but
> likely still works.
> 
> That goes under /etc/portage/ by the way.  I think you know that already
> but just in case.  I have those moments too.  ;-) 
> 
> That helps??

I think its in /etc/portage/profile instead.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: [gentoo-user] using package.provided

[Dale]

covici@ccs.covici.com wrote:
> Dale <rdalek1967@gmail.com> wrote:
>
>> Harry Putnam wrote:
>>> I'd like to stay on kernel-4.1.6, rather than keep installing the
>>> newest version at each upgrade.
>>>
>>> As I recall, and a quick look at `man portage', a file named
>>> `package.provided' is meant for such things.
>>>
>>> The syntax is not described in detail... I tried these:
>>>
>>>   /etc/portage/package.provided
>>>
>>>   >=sys-kernel/gentoo-sources-4.1.6
>>>
>>> Still `emerge -vp gentoo-sources' indicates it will install the most
>>> recent kernel.
>>>
>>> then I noticed the portage man page, under `Format' does say:
>>> "relational operators are not allowed"
>>> So I dropped the `>=' part
>>>
>>>   sys-kernel/gentoo-sources-4.1.6
>>>
>>> Same result from `emerge -vp gentoo-sources' . . .
>>>
>>> What am I forgetting?
>>>
>>>
>>>
>>
>> This is how I do this sort of thing.  I add the name and version to
>> package.mask which stops future updates/upgrades.  Example, for my
>> nvidia drivers, this is in package.mask.
>>
>>> =x11-drivers/nvidia-drivers-341.0.0 
>> That tells portage that anything above that version is masked locally
>> and not to update it.  For what you want, this should work:
>>
>>> sys-kernel/gentoo-sources-4.1.6
>> I removed the equal sign since you want to keep that version around but
>> nothing above it.  If portage doesn't like that, you may want to use the
>> next version up and have the ">=" in front.  According to what I have
>> here, it would be like this:
>>
>>> =sys-kernel/gentoo-sources-4.1.12 
>> I actually don't show a 4.1.6 here right now.  Removed I guess but
>> likely still works.
>>
>> That goes under /etc/portage/ by the way.  I think you know that already
>> but just in case.  I have those moments too.  ;-) 
>>
>> That helps??
> I think its in /etc/portage/profile instead.
>


Mine here is in:  /etc/portage/package.mask  It's been there for a long
time.  Maybe they are moving things again to something new but it works
here. 

Dale

:-)  :-) 

Re: [gentoo-user] using package.provided

[Neil Bothwick]

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

On Thu, 25 Feb 2016 15:47:32 -0600, Dale wrote:

> Mine here is in:  /etc/portage/package.mask  It's been there for a long
> time.  Maybe they are moving things again to something new but it works
> here. 

Things that override global settings in make.conf, like package.mask, go
in /etc/portage. Things that override profile settings go
in /etc/portage/profile.

If in doubt, read man portage which explains all these files.


-- 
Neil Bothwick

Only an idiot actually READS taglines.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] using package.provided

[Dale]

Neil Bothwick wrote:
> On Thu, 25 Feb 2016 15:47:32 -0600, Dale wrote:
>
>> Mine here is in:  /etc/portage/package.mask  It's been there for a long
>> time.  Maybe they are moving things again to something new but it works
>> here. 
> Things that override global settings in make.conf, like package.mask, go
> in /etc/portage. Things that override profile settings go
> in /etc/portage/profile.
>
> If in doubt, read man portage which explains all these files.
>
>


All I know, it works here.  What the OP is wanting to do is no different
than what I am doing here except that it is a different package.  So, if
it works here, it should work there too.  I might add, I don't even have
the profile directory at all. 

Dale

:-)  :-) 

Re: [gentoo-user] using package.provided

[Neil Bothwick]

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

On Fri, 26 Feb 2016 03:39:22 -0600, Dale wrote:

> >> Mine here is in:  /etc/portage/package.mask  It's been there for a
> >> long time.  Maybe they are moving things again to something new but
> >> it works here.   
> > Things that override global settings in make.conf, like package.mask,
> > go in /etc/portage. Things that override profile settings go
> > in /etc/portage/profile.
> >
> > If in doubt, read man portage which explains all these files.

> All I know, it works here.  What the OP is wanting to do is no different
> than what I am doing here except that it is a different package.  So, if
> it works here, it should work there too.  I might add, I don't even have
> the profile directory at all. 

But then you don't use package.provided. If you did, it wouldn't work
unless it was in /etc/portage/profile.


-- 
Neil Bothwick

I wouldn't be caught dead with a necrophiliac.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] using package.provided

[Dale]

Neil Bothwick wrote:
> On Fri, 26 Feb 2016 03:39:22 -0600, Dale wrote:
>
>>>> Mine here is in:  /etc/portage/package.mask  It's been there for a
>>>> long time.  Maybe they are moving things again to something new but
>>>> it works here.   
>>> Things that override global settings in make.conf, like package.mask,
>>> go in /etc/portage. Things that override profile settings go
>>> in /etc/portage/profile.
>>>
>>> If in doubt, read man portage which explains all these files.
>> All I know, it works here.  What the OP is wanting to do is no different
>> than what I am doing here except that it is a different package.  So, if
>> it works here, it should work there too.  I might add, I don't even have
>> the profile directory at all. 
> But then you don't use package.provided. If you did, it wouldn't work
> unless it was in /etc/portage/profile.
>
>

Although the OP asked about package.provided, it isn't what he needs to
use.  As you pointed out in another reply, he needs package.mask and it
goes in /etc/portage/.  It doesn't really matter if the OP has a profile
directory or not since he doesn't need to use that in this case.  He
just needs to use package.mask and add the correct info there.  After
that, the OP is done. 

Dale

:-)  :-)