[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] Re: using package.provided

[Nikos Chantziaras]

On 25/02/16 05:55, Harry Putnam wrote:
> I'd like to stay on kernel-4.1.6, rather than keep installing the
> newest version at each upgrade.

I'd instead recommend putting

   >=sys-kernel/gentoo-sources-4.2

in package.mask to stay with 4.1 (it's an LTS kernel) and always get the 
patches for that one.

[gentoo-user] Re: using package.provided

[Harry Putnam]

First off, thanks to all posters for the excellent input

> Nikos Chantziaras <realnc@gmail.com> writes:

> On 25/02/16 05:55, Harry Putnam wrote:
>> I'd like to stay on kernel-4.1.6, rather than keep installing the
>> newest version at each upgrade.
>
> I'd instead recommend putting
>
>   >=sys-kernel/gentoo-sources-4.2
>
> in package.mask to stay with 4.1 (it's an LTS kernel) and always get
> the patches for that one.

In /etc/portage/package-mask, using the line you suggest:

  >=sys-kernel/gentoo-sources-4.2

Makes emerge want to install 4.1.18:

  emerge -vp gentoo-sources
   [...]
  Calculating dependencies... done!
  [ebuild  NS    ] sys-kernel/gentoo-sources-4.1.18:4.1.18::gentoo
  [4.1.6:4.1.6::gentoo] USE="-build -experimental -kdbus -symlink" 575 KiB

Using `>=sys-kernel/gentoo-sources-4.1.6'
emerge wants to install 4.0.9:

   [ebuild  NS    ] sys-kernel/gentoo-sources-4.0.9:4.0.9::gentoo
   [...]

Using `>sys-kernel/gentoo-sources-4.1.6'
emerge want to install 4.0.9 as well

  [ebuild  NS    ] sys-kernel/gentoo-sources-4.0.9:4.0.9::gentoo [...]

So apparently none of the suggestions causes emerge to just stay with 4.1.6    

-------       -------       ---=---       -------       -------

However, after creating /etc/portage/profile and placing
package.provided with `sys-kernel/gentoo-sources-4.1.6' inside.
(NOTE:package.provided does not allow any <,>,= type signs)

root # emerge -vp gentoo-sources

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

  Calculating dependencies... done!

  Total: 0 packages, Size of downloads: 0 KiB

  WARNING: A requested package will not be merged because it is listed in
  package.provided:

  gentoo-sources pulled in by 'args'

This appears to do what I was after.  Should I expect any `gotchas'?

[gentoo-user] Re: using package.provided

[Nikos Chantziaras]

On 26/02/16 18:47, Harry Putnam wrote:
> First off, thanks to all posters for the excellent input
>
>> Nikos Chantziaras <realnc@gmail.com> writes:
>
>> On 25/02/16 05:55, Harry Putnam wrote:
>>> I'd like to stay on kernel-4.1.6, rather than keep installing the
>>> newest version at each upgrade.
>>
>> I'd instead recommend putting
>>
>>    >=sys-kernel/gentoo-sources-4.2
>>
>> in package.mask to stay with 4.1 (it's an LTS kernel) and always get
>> the patches for that one.
>
> In /etc/portage/package-mask, using the line you suggest:
>
>    >=sys-kernel/gentoo-sources-4.2
>
> Makes emerge want to install 4.1.18:

Yes, which is what I recommended. Don't block 4.1.x security/bugfix 
patches. Just block 4.2 and above.

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

[Rich Freeman]

On Fri, Feb 26, 2016 at 4:15 PM, Nikos Chantziaras <realnc@gmail.com> wrote:
>
> Yes, which is what I recommended. Don't block 4.1.x security/bugfix patches.
> Just block 4.2 and above.
>

++

4.1 is a longterm series, so if your goal is minimum disruption you
can stay on it until Sep 2017.  I would still recommend taking the
4.1.x updates both for backports and possible security updates.

I personally just have my own git tree.  It is easy to just update it
in place vs unpacking huge tarballs every time there is a patch
release, and I'm less-tied to the Gentoo maintainers.  They do a great
job, but since I run btrfs I tend to be really picky about what kernel
series I'm on.

The one thing I'd love to see upstreamed is the openrc/systemd/etc
convenience configuration items.

-- 
Rich

[gentoo-user] Re: using package.provided

[Harry Putnam]

Nikos Chantziaras <realnc@gmail.com> writes:

> On 26/02/16 18:47, Harry Putnam wrote:
>> First off, thanks to all posters for the excellent input
>>
>>> Nikos Chantziaras <realnc@gmail.com> writes:
>>
>>> On 25/02/16 05:55, Harry Putnam wrote:
>>>> I'd like to stay on kernel-4.1.6, rather than keep installing the
>>>> newest version at each upgrade.
>>>
>>> I'd instead recommend putting
>>>
>>>    >=sys-kernel/gentoo-sources-4.2
>>>
>>> in package.mask to stay with 4.1 (it's an LTS kernel) and always get
>>> the patches for that one.
>>
>> In /etc/portage/package-mask, using the line you suggest:
>>
>>    >=sys-kernel/gentoo-sources-4.2
>>
>> Makes emerge want to install 4.1.18:
>
> Yes, which is what I recommended. Don't block 4.1.x security/bugfix
> patches. Just block 4.2 and above.

Ahh... now I get what your saying..  Some of your previous comments
slid right over my thick skull.  Thank you.