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