[gentoo-user] Re: using package.provided

2016-02-27 Thread Harry Putnam
Nikos Chantziaras  writes:

> On 26/02/16 18:47, Harry Putnam wrote:
>> First off, thanks to all posters for the excellent input
>>
>>> Nikos Chantziaras  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.




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

2016-02-26 Thread Rich Freeman
On Fri, Feb 26, 2016 at 4:15 PM, Nikos Chantziaras  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

2016-02-26 Thread Nikos Chantziaras

On 26/02/16 18:47, Harry Putnam wrote:

First off, thanks to all posters for the excellent input


Nikos Chantziaras  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.





[gentoo-user] Re: using package.provided

2016-02-26 Thread Harry Putnam
First off, thanks to all posters for the excellent input

> Nikos Chantziaras  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

2016-02-25 Thread 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

2006-12-22 Thread reader
Alan McKinnon [EMAIL PROTECTED] 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

2006-12-22 Thread Neil Bothwick
On Fri, 22 Dec 2006 11:05:40 -0600, [EMAIL PROTECTED] 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...


signature.asc
Description: PGP signature


[gentoo-user] Re: using package.provided

2006-12-21 Thread reader
Alan McKinnon [EMAIL PROTECTED] 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

2006-12-21 Thread reader
Neil Bothwick [EMAIL PROTECTED] 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

2006-12-21 Thread reader
Alan McKinnon [EMAIL PROTECTED] writes:

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

-- 
gentoo-user@gentoo.org mailing list