Re: [gentoo-user] package.provided syntax for overlay
On Sun, 19 Feb 2017 11:17:11 +, Mick wrote: > > Another option is to copy/symlink the specific package you want from > > the bar overlay to your local overlay and do not include the bar > > overlay in repos.conf. > > Sorry for being dense. Do you mean first add the overlay with 'layman > -a bar', then symlink the particular package to my local overlay? Yes. > How > will I be updating this package in the future, if I do not have the > 'bar' overlay settings in /etc/portage/repos.conf/layman.conf? Layman will still update all its overlays when you run layman -S, but portage will not see the contents. I've used this method often when I want a single package from an overlay. You may have to link more than one package to satisfy dependencies, but that is not usually the case in my experience. -- Neil Bothwick Where do you think you're going today? pgpNWlsu4j_Dd.pgp Description: OpenPGP digital signature
Re: [gentoo-user] package.provided syntax for overlay
On Sunday 19 Feb 2017 10:50:31 Neil Bothwick wrote: > On Sun, 19 Feb 2017 11:45:27 +0100, Johannes Rosenberger wrote: > > > So I tried in /etc/portage/package.provided any combination of these: > > > > > > x11-wm/enlightenment-:0.17/::bar > > > > > > =x11-wm/enlightenment-:0.17 > > > > > > x11-wm/enlightenment- > > > > > > None of which can stop portage dragging in 'x11- > > > wm/enlightenment-:0.17/::bar'. What is the correct syntax to > > > block this version of enlightenment from emerging? > > > > According to the portage manpage 'x11-wm/enlightenment-' should be > > the correct syntax. > > > > But I think, package.provided is the wrong file at all. The correct way > > to accomplish what you want to is masking > > 'x11-wm/enlightenment-:0.17/::bar'. > > Agreed. > > Another option is to copy/symlink the specific package you want from the > bar overlay to your local overlay and do not include the bar overlay in > repos.conf. Sorry for being dense. Do you mean first add the overlay with 'layman -a bar', then symlink the particular package to my local overlay? How will I be updating this package in the future, if I do not have the 'bar' overlay settings in /etc/portage/repos.conf/layman.conf? I'm trying to understand the benefit of doing it as you suggest above ... :-/ -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] package.provided syntax for overlay
On Sunday 19 Feb 2017 11:45:27 Johannes Rosenberger wrote: > On 19.02.2017 11:20, Mick wrote: > > Hi All, > > > > Given sddm is not working for my setup, as per bug #608690, I thought of > > trying entrance from the bar overlay. It wants to pull in enlightenment, > > which I have already installed from the main tree and would like to keep > > it as such: > > > > # emerge -uaDv entrance > > > > These are the packages that would be merged, in order: > > > > Calculating dependencies... done! > > [ebuild U ~] x11-wm/enlightenment-:0.17/::bar > > [0.20.6:0.17/0.20.6::gentoo] USE="eeze%* nls pam ukit -doc -egl% > > -pm-utils% - static-libs -systemd -wayland (-spell%*)" > > ENLIGHTENMENT_MODULES="appmenu backlight battery bluez4 clock > > conf-applications conf-bindings conf-dialogs conf-display > > conf-interaction conf-intl conf-menus conf-paths conf-performance > > conf-randr conf-shelves conf-theme conf-window-manipulation conf-window- > > remembers connman contact%* cpufreq everything fileman fileman-opinfo > > gadman ibar ibox lokker mixer msgbus music-control notification pager > > pager16%* quickaccess shot start syscon systray tasks teamwork > > temperature tiling winlist wizard xkbswitch -access% -packagkit% > > -wl-desktop-shell* -wl-drm* -wl- fb% -wl-x11* (-conf%*) (-geolocation%*) > > (-packagekit%*) (-pager-plain%*) (- policy-mobile%*) (-wl-text-input%*) > > (-wl-weekeyboard%*) (-wl-wl%*) (- xwayland%*)" 0 KiB > > [ebuild N*] x11-plugins/entrance-::bar USE="consolekit pam -grub > > - systemd -vkbd" 0 KiB > > > > > > So I tried in /etc/portage/package.provided any combination of these: > > > > x11-wm/enlightenment-:0.17/::bar > > > > =x11-wm/enlightenment-:0.17 > > > > x11-wm/enlightenment- > > > > None of which can stop portage dragging in 'x11- > > wm/enlightenment-:0.17/::bar'. What is the correct syntax to > > block > > this version of enlightenment from emerging? > > According to the portage manpage 'x11-wm/enlightenment-' should be > the correct syntax. > > But I think, package.provided is the wrong file at all. The correct way > to accomplish what you want to is masking > 'x11-wm/enlightenment-:0.17/::bar'. The problem with this > package is that it is keyworded incorrectly as '~amd64 ~x86' despite > being a live ebuild. > If you already have enlightenment:0.17 installed this should suffice, > since entrance only depends on this and not the live ebuild. Thank you Johannes, I removed package.provided and added '=x11- wm/enlightenment-:0.17' in package.mask. Now it wants to install: x11-wm/enlightenment-0.21.3:0.17/0.21::bar so I added that version in package.mask too and it now is emerging entrance. :-) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] package.provided syntax for overlay
On Sun, 19 Feb 2017 11:45:27 +0100, Johannes Rosenberger wrote: > > So I tried in /etc/portage/package.provided any combination of these: > > > > x11-wm/enlightenment-:0.17/::bar > > > > =x11-wm/enlightenment-:0.17 > > > > x11-wm/enlightenment- > > > > None of which can stop portage dragging in 'x11- > > wm/enlightenment-:0.17/::bar'. What is the correct syntax to > > block this version of enlightenment from emerging? > > > According to the portage manpage 'x11-wm/enlightenment-' should be > the correct syntax. > > But I think, package.provided is the wrong file at all. The correct way > to accomplish what you want to is masking > 'x11-wm/enlightenment-:0.17/::bar'. Agreed. Another option is to copy/symlink the specific package you want from the bar overlay to your local overlay and do not include the bar overlay in repos.conf. -- Neil Bothwick Change is inevitable. Except from a vending machine. pgpqRAjluxWjL.pgp Description: OpenPGP digital signature
Re: [gentoo-user] package.provided syntax for overlay
On 19.02.2017 11:20, Mick wrote: > Hi All, > > Given sddm is not working for my setup, as per bug #608690, I thought of > trying entrance from the bar overlay. It wants to pull in enlightenment, > which I have already installed from the main tree and would like to keep it > as > such: > > # emerge -uaDv entrance > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild U ~] x11-wm/enlightenment-:0.17/::bar > [0.20.6:0.17/0.20.6::gentoo] USE="eeze%* nls pam ukit -doc -egl% -pm-utils% - > static-libs -systemd -wayland (-spell%*)" ENLIGHTENMENT_MODULES="appmenu > backlight battery bluez4 clock conf-applications conf-bindings conf-dialogs > conf-display conf-interaction conf-intl conf-menus conf-paths > conf-performance > conf-randr conf-shelves conf-theme conf-window-manipulation conf-window- > remembers connman contact%* cpufreq everything fileman fileman-opinfo gadman > ibar ibox lokker mixer msgbus music-control notification pager pager16%* > quickaccess shot start syscon systray tasks teamwork temperature tiling > winlist wizard xkbswitch -access% -packagkit% -wl-desktop-shell* -wl-drm* -wl- > fb% -wl-x11* (-conf%*) (-geolocation%*) (-packagekit%*) (-pager-plain%*) (- > policy-mobile%*) (-wl-text-input%*) (-wl-weekeyboard%*) (-wl-wl%*) (- > xwayland%*)" 0 KiB > [ebuild N*] x11-plugins/entrance-::bar USE="consolekit pam -grub - > systemd -vkbd" 0 KiB > > > So I tried in /etc/portage/package.provided any combination of these: > > x11-wm/enlightenment-:0.17/::bar > > =x11-wm/enlightenment-:0.17 > > x11-wm/enlightenment- > > None of which can stop portage dragging in 'x11- > wm/enlightenment-:0.17/::bar'. What is the correct syntax to block > this version of enlightenment from emerging? > According to the portage manpage 'x11-wm/enlightenment-' should be the correct syntax. But I think, package.provided is the wrong file at all. The correct way to accomplish what you want to is masking 'x11-wm/enlightenment-:0.17/::bar'. The problem with this package is that it is keyworded incorrectly as '~amd64 ~x86' despite being a live ebuild. If you already have enlightenment:0.17 installed this should suffice, since entrance only depends on this and not the live ebuild.
[gentoo-user] package.provided syntax for overlay
Hi All, Given sddm is not working for my setup, as per bug #608690, I thought of trying entrance from the bar overlay. It wants to pull in enlightenment, which I have already installed from the main tree and would like to keep it as such: # emerge -uaDv entrance These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ~] x11-wm/enlightenment-:0.17/::bar [0.20.6:0.17/0.20.6::gentoo] USE="eeze%* nls pam ukit -doc -egl% -pm-utils% - static-libs -systemd -wayland (-spell%*)" ENLIGHTENMENT_MODULES="appmenu backlight battery bluez4 clock conf-applications conf-bindings conf-dialogs conf-display conf-interaction conf-intl conf-menus conf-paths conf-performance conf-randr conf-shelves conf-theme conf-window-manipulation conf-window- remembers connman contact%* cpufreq everything fileman fileman-opinfo gadman ibar ibox lokker mixer msgbus music-control notification pager pager16%* quickaccess shot start syscon systray tasks teamwork temperature tiling winlist wizard xkbswitch -access% -packagkit% -wl-desktop-shell* -wl-drm* -wl- fb% -wl-x11* (-conf%*) (-geolocation%*) (-packagekit%*) (-pager-plain%*) (- policy-mobile%*) (-wl-text-input%*) (-wl-weekeyboard%*) (-wl-wl%*) (- xwayland%*)" 0 KiB [ebuild N*] x11-plugins/entrance-::bar USE="consolekit pam -grub - systemd -vkbd" 0 KiB So I tried in /etc/portage/package.provided any combination of these: x11-wm/enlightenment-:0.17/::bar =x11-wm/enlightenment-:0.17 x11-wm/enlightenment- None of which can stop portage dragging in 'x11- wm/enlightenment-:0.17/::bar'. What is the correct syntax to block this version of enlightenment from emerging? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] package.provided?
Harry Putnam wrote:
Setup:
Installing X on Vbox vm runnning gentoo (amd64 not strict). Host
is win10 (64bit)
Installing the xorg-server is calling for the installation of
app-emulation/virtualbox-guest-additions-5.0.32
However, my version of vbox is for a windows host (5.1.14). And
actually has the guest additions for that version already installed.
Also before I noticed what was getting installed emerge had tried and
failed to install the cited above package.
I noticed the version that matches my vbox version (5.1.14) is
available but masked unless setting ~amd64. I'm trying for a stable
setup so, put this in /etc/portage/package.accept_keywords:
=app-emulation/virtualbox-guest-additions-5.1.14 ~amd64
I tried to emerge it directly with:
emerge app-emulation/virtualbox-guest-additions
And sure enough emerge selected the right version but again the
install failed. I did not understand the failure from the build log.
But since I have the proper version and am able to install it with the
regular method vbox expects (mount the additions and install with
sh VBoxLinuxAdditions.run
And since that method uses the currently installed kernel for its
installation. Seems I can just reinstall the addtions using that
method and tell gentoo about it with package.provided.
Again no solution from me, but looking at the virtualbox-guest-additions-5.1.14.ebuild
there is a postinst log which you probably did not see due to the emerge failure, that
suggests a number of operations required to make the guest additions work properly:
elog "Please add users to the \"vboxguest\" group so they can"
elog "benefit from seamless mode, auto-resize and clipboard."
elog ""
elog "The vboxsf group has been added to make automount services work."
elog "These services are part of the shared folders support."
elog ""
elog "Please add:"
elog "/etc/init.d/${PN}"
elog "to the default runlevel in order to start"
elog "needed services."
elog "To use the VirtualBox X driver, use the following"
elog "file as your /etc/X11/xorg.conf:"
elog "/usr/share/doc/${PF}/xorg.conf.vbox"
elog ""
elog "Also make sure you use the Mesa library for OpenGL:"
elog "eselect opengl set xorg-x11"
elog ""
elog "An autostart .desktop file has been installed to start"
elog "VBoxClient in desktop sessions."
elog ""
elog "You can mount shared folders with:"
elog "mount -t vboxsf "
elog ""
elog "Warning:"
elog "this ebuild is only needed if you are running gentoo"
elog "inside a VirtualBox Virtual Machine, you don't need"
elog "it to run VirtualBox itself."
If you did not do the above you might incur in trouble later. Apart from this if I were
you I'd try to understand why the guest-additions emerge failed. Maybe you could try to
post the ebuild log?
raffaele
Re: [gentoo-user] package.provided?
On 14.02.2017 16:09, Harry Putnam wrote: > Setup: > >Installing X on Vbox vm runnning gentoo (amd64 not strict). Host >is win10 (64bit) > > Installing the xorg-server is calling for the installation of > app-emulation/virtualbox-guest-additions-5.0.32 > > However, my version of vbox is for a windows host (5.1.14). And > actually has the guest additions for that version already installed. > > Also before I noticed what was getting installed emerge had tried and > failed to install the cited above package. > > I noticed the version that matches my vbox version (5.1.14) is > available but masked unless setting ~amd64. I'm trying for a stable > setup so, put this in /etc/portage/package.accept_keywords: > > =app-emulation/virtualbox-guest-additions-5.1.14 ~amd64 > > I tried to emerge it directly with: >emerge app-emulation/virtualbox-guest-additions > > And sure enough emerge selected the right version but again the > install failed. I did not understand the failure from the build log. > > But since I have the proper version and am able to install it with the > regular method vbox expects (mount the additions and install with > > sh VBoxLinuxAdditions.run > > And since that method uses the currently installed kernel for its > installation. Seems I can just reinstall the addtions using that > method and tell gentoo about it with package.provided. > > Ok, `man portage' does not appear to mention where that file should > reside. Googling about it I find /etc/portage/profile is mentioned. > Is that still correct? > > I ask because I put /etc/portage/profile/package.provided: > > =app-emulation/virtualbox-guest-additions-5.0.32 > > (removed the prior /etc/portage/package.accept_keywords/ > virtualbox-guest-additions: > =app-emulation/virtualbox-guest-additions-5.1.14 ~amd64) > > in place, but emerge still tries to install it so, either the syntax > if faulty or the location is, I guess. > > I moved package.provided to /etc/portage/package.provided but still > emerge trys to install the guest-additions. > > Can anyone offer suggestions about this... is it even the right way to > proceed? > > Hello! I have portage-2.3.3 installed and in my portage manpage it is mentioned: The file shall reside in etc/(make.profile|portage/(make.)?profile) and the syntax is /- without the '=' in the front. Greetz Johannes
[gentoo-user] package.provided?
Setup: Installing X on Vbox vm runnning gentoo (amd64 not strict). Host is win10 (64bit) Installing the xorg-server is calling for the installation of app-emulation/virtualbox-guest-additions-5.0.32 However, my version of vbox is for a windows host (5.1.14). And actually has the guest additions for that version already installed. Also before I noticed what was getting installed emerge had tried and failed to install the cited above package. I noticed the version that matches my vbox version (5.1.14) is available but masked unless setting ~amd64. I'm trying for a stable setup so, put this in /etc/portage/package.accept_keywords: =app-emulation/virtualbox-guest-additions-5.1.14 ~amd64 I tried to emerge it directly with: emerge app-emulation/virtualbox-guest-additions And sure enough emerge selected the right version but again the install failed. I did not understand the failure from the build log. But since I have the proper version and am able to install it with the regular method vbox expects (mount the additions and install with sh VBoxLinuxAdditions.run And since that method uses the currently installed kernel for its installation. Seems I can just reinstall the addtions using that method and tell gentoo about it with package.provided. Ok, `man portage' does not appear to mention where that file should reside. Googling about it I find /etc/portage/profile is mentioned. Is that still correct? I ask because I put /etc/portage/profile/package.provided: =app-emulation/virtualbox-guest-additions-5.0.32 (removed the prior /etc/portage/package.accept_keywords/ virtualbox-guest-additions: =app-emulation/virtualbox-guest-additions-5.1.14 ~amd64) in place, but emerge still tries to install it so, either the syntax if faulty or the location is, I guess. I moved package.provided to /etc/portage/package.provided but still emerge trys to install the guest-additions. Can anyone offer suggestions about this... is it even the right way to proceed?
[gentoo-user] package.provided messes up emerging of package slots?
In my /etc/portage/profile/package.provided, I have this: media-libs/freetype-1.4_pre20080316-r2 When I try to emerge freetype however, instead of emerging the newer version, I get: $ emerge freetype WARNING: A requested package will not be merged because it is listed in package.provided: freetype pulled in by 'args' Nothing to merge; would you like to auto-clean packages? [Yes/No] Trying emerge freetype:2 also won't work. The only only to emerge it seems is by using the whole version (emerge =freetype-2.4.6). Is this a bug?
Re: [gentoo-user] package.provided messes up emerging of package slots?
On Sep 12, 2011 11:11 PM, Nikos Chantziaras rea...@arcor.de wrote: In my /etc/portage/profile/package.provided, I have this: media-libs/freetype-1.4_pre20080316-r2 When I try to emerge freetype however, instead of emerging the newer version, I get: $ emerge freetype WARNING: A requested package will not be merged because it is listed in package.provided: freetype pulled in by 'args' Nothing to merge; would you like to auto-clean packages? [Yes/No] Trying emerge freetype:2 also won't work. The only only to emerge it seems is by using the whole version (emerge =freetype-2.4.6). Is this a bug? Why did you have that line in package.provided, in the first place? Did you install freetype on your own, without using portage? The way I see it, Portage worked perfectly: it saw that you have installed a certain version of freetype on your own, and it didn't want to mess up your installed package. Just delete the line and emerge freetype. (someone please CMIIW) Rgds,
Re: [gentoo-user] package.provided messes up emerging of package slots?
On Monday, 12. September 2011 18:41:37 Nikos Chantziaras wrote: In my /etc/portage/profile/package.provided, I have this: media-libs/freetype-1.4_pre20080316-r2 When I try to emerge freetype however, instead of emerging the newer version, I get: $ emerge freetype WARNING: A requested package will not be merged because it is listed in package.provided: freetype pulled in by 'args' Nothing to merge; would you like to auto-clean packages? [Yes/No] Trying emerge freetype:2 also won't work. The only only to emerge it seems is by using the whole version (emerge =freetype-2.4.6). Is this a bug? At least it's inconsistent. I would expect that the emerge with complete version also fails. Regards, Michael
[gentoo-user] package.provided
Hi, I want to compile mplayer in a way not supported by the ebuild and use portage only to keep record of the files installed in system for future uninstallation. The system amd64 stable. I have done the following: (1) echo media-video/mplayer /etc/portage/package.keywords // emerge -p mplayer now gives: media-video/mplayer-1.0_rc2_p24929-r2 // (2) echo media-video/mplayer-1.0_rc2_p24929-r2 /etc/portage/package.provided (3) ebuild `equery w mplayer` unpack (4) cd $PORTAGE_TMPDIR/portage/media-video/mplayer-*/work/mplayer* (5) ./configure --the-way-I-want-it-to-be (6)make (7) cd ../../ (8) touch .compiled (9) ebuild `equery w mplayer` merge Everything seems to be OK until I try emerge -DuNav world. After this point portage wants to rebuild mplayer, showing all USE flags as newly added (e.g. alsa%). I expected putting mplayer into /etc/portage/package.keywords to make portage ignore this package. Where is my mistake and what is the correct method I should follow? -- Best regards, Daniel -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] package.provided
On Tuesday 08 January 2008, Daniel Iliev wrote: Hi, I want to compile mplayer in a way not supported by the ebuild and use portage only to keep record of the files installed in system for future uninstallation. A much better way would be to modify the ebuild to do what you want, then copy it to a local overlay. Portage will use your overlay in preference to the portage tree. You just have to then watch out for newer versions to hit the tree which will supercede your custom ebuild, and modify those new versions similarly. There's an environment variable EXTRA_ECONF intended for *users* to add extra configure options when emerging, but I have heard bad things about using this. Don't know the details, perhaps someone else who does will post in response. Finally, you could just mask out mplayer entirely and build it from source using the default DESTDIR of /usr/local. It's not a complete unistall solution, but at least it doesn't collide with portage's installs in /usr/ man 5 ebuild has lots of info on this topic alan The system amd64 stable. I have done the following: (1) echo media-video/mplayer /etc/portage/package.keywords // emerge -p mplayer now gives: media-video/mplayer-1.0_rc2_p24929-r2 // (2) echo media-video/mplayer-1.0_rc2_p24929-r2 /etc/portage/package.provided (3) ebuild `equery w mplayer` unpack (4) cd $PORTAGE_TMPDIR/portage/media-video/mplayer-*/work/mplayer* (5) ./configure --the-way-I-want-it-to-be (6)make (7) cd ../../ (8) touch .compiled (9) ebuild `equery w mplayer` merge Everything seems to be OK until I try emerge -DuNav world. After this point portage wants to rebuild mplayer, showing all USE flags as newly added (e.g. alsa%). I expected putting mplayer into /etc/portage/package.keywords to make portage ignore this package. Where is my mistake and what is the correct method I should follow? -- Best regards, Daniel -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] package.provided
On Tue, 8 Jan 2008 14:35:27 +0200 Daniel Iliev [EMAIL PROTECTED] wrote: I want to compile mplayer in a way not supported by the ebuild and use portage only to keep record of the files installed in system for future uninstallation. The system amd64 stable. I have done the following: (1) echo media-video/mplayer /etc/portage/package.keywords // emerge -p mplayer now gives: media-video/mplayer-1.0_rc2_p24929-r2 // (2) echo media-video/mplayer-1.0_rc2_p24929-r2 /etc/portage/package.provided (3) ebuild `equery w mplayer` unpack (4) cd $PORTAGE_TMPDIR/portage/media-video/mplayer-*/work/mplayer* (5) ./configure --the-way-I-want-it-to-be (6)make (7) cd ../../ (8) touch .compiled (9) ebuild `equery w mplayer` merge Everything seems to be OK until I try emerge -DuNav world. After this point portage wants to rebuild mplayer, showing all USE flags as newly added (e.g. alsa%). I expected putting mplayer into /etc/portage/package.keywords to make portage ignore this package. Where is my mistake and what is the correct method I should follow? The correct method is described, for example, in the following email: http://archives.gentoo.org/gentoo-user/msg_119794.xml Cheers, Renat -- Probleme kann man niemals mit derselben Denkweise loesen, durch die sie entstanden sind. (Einstein) signature.asc Description: PGP signature
Re: [gentoo-user] package.provided
On Tue, 8 Jan 2008 15:11:09 +0200 Alan McKinnon [EMAIL PROTECTED] wrote: A much better way would be to modify the ebuild to do what you want, then copy it to a local overlay. Portage will use your overlay in preference to the portage tree. You just have to then watch out for newer versions to hit the tree which will supercede your custom ebuild, and modify those new versions similarly. Yes, may be it's time for me to learn how to write an ebuild. My problem is that it seems to me too much work just to maintain a few occasional packages locally. ;-) There's an environment variable EXTRA_ECONF intended for *users* to add extra configure options when emerging, but I have heard bad things about using this. Don't know the details, perhaps someone else who does will post in response. Yes, I'm aware of EXTRA_ECONF and I use it via /etc/portage/bashrc. ( explained w/ example by Mr. Bo Andresen: http://tinyurl.com/39c74x ) It never caused problems here. I want to change the ./configure --params for sure but perhaps I'd need to alter several source files. I'm not sure if /etc/portage/bashrc could do the work in the latter case but it's an idea that never occurred to me before and I'm going to explore. Finally, you could just mask out mplayer entirely and build it from source using the default DESTDIR of /usr/local. It's not a complete unistall solution, but at least it doesn't collide with portage's installs in /usr/ Why mask? If I install it manually there would be no need for emerge mplayer at all, right? ;-) (additionally /usr/local/(s)bin precedes /usr/(s)bin in $PATH by default) Anyways, this is not an option for me because I hate cleaning forgotten files or keeping the src for eventual make uninstall. I'd prefer compiling the program with PREFIX=$HOME/program_name. So, for the time being I'll try to solve the problem via /etc/portage/bashrc, while waiting for more possible advices. -- Best regards, Daniel -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] package.provided
On Tuesday 08 January 2008, Daniel Iliev wrote: On Tue, 8 Jan 2008 15:11:09 +0200 Alan McKinnon [EMAIL PROTECTED] wrote: A much better way would be to modify the ebuild to do what you want, then copy it to a local overlay. Portage will use your overlay in preference to the portage tree. You just have to then watch out for newer versions to hit the tree which will supercede your custom ebuild, and modify those new versions similarly. Yes, may be it's time for me to learn how to write an ebuild. My problem is that it seems to me too much work just to maintain a few occasional packages locally. ;-) It is a reasonable amount of work to read the man pages and so on, but I found it was well worth the trouble. Now when I read an ebuild I understand what I'm seeing, before it was just meaningless stuff. Am I correct in saying you plan to emerge mplayer with a few extra params and not much else customizing? In that case the mods you will make are simple and need to be done just once. Then paste the same changes into a new ebuild each time you want to upgrade There's an environment variable EXTRA_ECONF intended for *users* to add extra configure options when emerging, but I have heard bad things about using this. Don't know the details, perhaps someone else who does will post in response. Yes, I'm aware of EXTRA_ECONF and I use it via /etc/portage/bashrc. ( explained w/ example by Mr. Bo Andresen: http://tinyurl.com/39c74x ) It never caused problems here. Interesting. I must find out more :-) I want to change the ./configure --params for sure but perhaps I'd need to alter several source files. I'm not sure if /etc/portage/bashrc could do the work in the latter case but it's an idea that never occurred to me before and I'm going to explore. Finally, you could just mask out mplayer entirely and build it from source using the default DESTDIR of /usr/local. It's not a complete unistall solution, but at least it doesn't collide with portage's installs in /usr/ Why mask? Just a safety net really, in case you one day forget and run 'emerge mplayer'. Not necessary for operation :-) -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] package.provided
On Tue, 8 Jan 2008 20:23:58 +0200
Alan McKinnon [EMAIL PROTECTED] wrote:
On Tuesday 08 January 2008, Daniel Iliev wrote:
On Tue, 8 Jan 2008 15:11:09 +0200
--snip--
Am I correct in saying you plan to emerge mplayer with a few extra
params and not much else customizing? In that case the mods you will
make are simple and need to be done just once. Then paste the same
changes into a new ebuild each time you want to upgrade
Actually the changes I want to make are not so few. The whole story is
that several days ago a friend of mine pointed me to a very cool
front-end for mplayer: http://smplayer.sourceforge.net/
Unfortunately it can't be found in portage yet.
Since it works with the plain mplayer I decided to get rid of the GUI
part (gmplayer). The USE flag -gtk disables the GUI, but smplayer
couldn't work with the produced mplayer. When I compiled mplayer
manually with --disable-gui, smplayer worked just fine.
Additionally I started playing around with the src and found that on my
system mplayer can hold any optimisation I force upon it and there are
no problems. :)
I have best results when it's compiled with --enable-sse2 and no
other mxx, 3dnow etc. stuff. This way mplayer produces:
CPUflags: MMX: 0 MMX2: 0 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 1
in the output.
Additionally I forced some gcc options on the source like this:
find . -type f -exec sed -i 's/ -O. //g; {} +
find . -type f -exec sed -i 's/-mtune=\w*//g' {} +
find . -type f -exec sed -i 's/-mcpu=\w*//g' {} +
find . -type f -exec sed -i 's/march=\w*/march=athlon64 \-msse3
\-mfpmath=sse \-O3\-pipe \-fomit-frame-pointer/g' {} +
// Yes, it's brutal and it's a miracle that it works but what do I have
to loose? The worst case scenario is that I end up with broken src and
have to extract it again :) //
Now mplayer uses up to 20% less CPU which in my case is not
meaningless.
The only problem is to make portage forget about this package until the
next version is released. I thought package.provided is for this
purpose, but it doesn't work here as I expected.
Yes, I'm aware of EXTRA_ECONF and I use it via /etc/portage/bashrc.
( explained w/ example by Mr. Bo Andresen: http://tinyurl.com/39c74x
) It never caused problems here.
Interesting. I must find out more :-)
It's very handy. For example I don't need the innodb engine of mysql,
so my /etc/portage/bashrc reads:
==
case $CATEGORY/$PN in
dev-db/mysql)
EXTRA_ECONF=--enable-local-infile --without-innodb
;;
esac
==
Unfortunately I couldn't manage to use it for solving the current
problem.
--
Best regards,
Daniel
--
gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] package.provided
On Tue, 8 Jan 2008 14:35:27 +0200, Daniel Iliev wrote: (1) echo media-video/mplayer /etc/portage/package.keywords This just causes portage to use the testing, ~arch version of the program (2) echo media-video/mplayer-1.0_rc2_p24929-r2 /etc/portage/package.provided This should be /etc/portage/profile/package.provided man portage explains the location and function of these files. -- Neil Bothwick Crayons can take you more places than starships. * Guinan signature.asc Description: PGP signature
Re: [gentoo-user] package.provided
On January 8, 2008, Daniel Iliev wrote: On Tue, 8 Jan 2008 20:23:58 +0200 Alan McKinnon [EMAIL PROTECTED] wrote: On Tuesday 08 January 2008, Daniel Iliev wrote: On Tue, 8 Jan 2008 15:11:09 +0200 --snip-- Am I correct in saying you plan to emerge mplayer with a few extra params and not much else customizing? In that case the mods you will make are simple and need to be done just once. Then paste the same changes into a new ebuild each time you want to upgrade Actually the changes I want to make are not so few. The whole story is that several days ago a friend of mine pointed me to a very cool front-end for mplayer: http://smplayer.sourceforge.net/ Unfortunately it can't be found in portage yet. http://smplayer.wiki.sourceforge.net/Contributed+Packages lists Berkano Overlay as a source for ebuild. You might want to check it out before you go too far building your own :) -- Dmitry Makovey Web Systems Administrator Athabasca University (780) 675-6245 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] package.provided
On Tue, 8 Jan 2008 14:35:27 +0200 Daniel Iliev [EMAIL PROTECTED] wrote: Hi, I want to compile mplayer in a way not supported by the ebuild and use portage only to keep record of the files installed in system for future uninstallation. The system amd64 stable. I have done the following: (1) echo media-video/mplayer /etc/portage/package.keywords // emerge -p mplayer now gives: media-video/mplayer-1.0_rc2_p24929-r2 // (2) echo media-video/mplayer-1.0_rc2_p24929-r2 /etc/portage/package.provided (3) ebuild `equery w mplayer` unpack (4) cd $PORTAGE_TMPDIR/portage/media-video/mplayer-*/work/mplayer* (5) ./configure --the-way-I-want-it-to-be (6)make (7) cd ../../ (8) touch .compiled (9) ebuild `equery w mplayer` merge Everything seems to be OK until I try emerge -DuNav world. After this point portage wants to rebuild mplayer, showing all USE flags as newly added (e.g. alsa%). I expected putting mplayer into /etc/portage/package.keywords to make portage ignore this package. Where is my mistake and what is the correct method I should follow? Pretty sure package.provided is /etc/portage/profile/package.provided -- Ken69267 signature.asc Description: PGP signature
Re: [gentoo-user] package.provided
On Tue, 8 Jan 2008 23:20:02 +0200, Daniel Iliev wrote: Actually the changes I want to make are not so few. The whole story is that several days ago a friend of mine pointed me to a very cool front-end for mplayer: http://smplayer.sourceforge.net/ Unfortunately it can't be found in portage yet. http://bugs.gentoo.org/show_bug.cgi?id=176211 -- Neil Bothwick Why isn't phonetically spelled that way? signature.asc Description: PGP signature
Re: [gentoo-user] package.provided
On Tue, 08 May 2007 13:13:05 -0700 Zac Medico [EMAIL PROTECTED] wrote: Daniel Iliev wrote: Following the official docs [1] I did echo x11-wm/aquamarine-0.2.1 /etc/portage/profile/package.provided but it doesn't seem to help. The way that emerge currently behaves, that won't help if aquamarine is listed in /var/lib/portage/world. If you've unmerged aquamarine since then, it will have been removed from the world file. I have never emerged aquamarine. It's not listed in the world file. -- Best regards, Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] package.provided
On Wed, 2007-05-09 at 12:22 +0300, Daniel Iliev wrote: On Tue, 08 May 2007 13:13:05 -0700 Zac Medico [EMAIL PROTECTED] wrote: Daniel Iliev wrote: Following the official docs [1] I did echo x11-wm/aquamarine-0.2.1 /etc/portage/profile/package.provided but it doesn't seem to help. should there be a = before the package name? HTH, -- Iain Buchanan iaindb at netspace dot net dot au Kindness is a language which the deaf can hear and the blind can read. -- Mark Twain -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] package.provided
On Wed, 09 May 2007 23:23:54 +0930, Iain Buchanan wrote: Following the official docs [1] I did echo x11-wm/aquamarine-0.2.1 /etc/portage/profile/package.provided but it doesn't seem to help. should there be a = before the package name? No, not for package.provided. -- Neil Bothwick Stupid user error. Terminate user (Y/n) ? signature.asc Description: PGP signature
[gentoo-user] package.provided
Hi, list I have x11-wm/beryl-0.2.1 installed on a stable system. One of its dependencies is ~x11-wm/aquamarine-0.2.1 which dies during compilation. This is fine with me because I installed beryl issuing: emerge --resume --skipfirst and it works OK. My problem is that portage wants to pull in aquamarine every time I execute: emerge -DuN world or emerge --depclean. Following the official docs [1] I did echo x11-wm/aquamarine-0.2.1 /etc/portage/profile/package.provided but it doesn't seem to help. Am I missing something? [1] http://shurl.org/NKiRs -- Best regards, Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] package.provided
I have x11-wm/beryl-0.2.1 installed on a stable system. One of its dependencies is ~x11-wm/aquamarine-0.2.1 which dies during compilation. This is fine with me because I installed beryl issuing: emerge --resume --skipfirst and it works OK. My problem is that portage wants to pull in aquamarine every time I execute: emerge -DuN world or emerge --depclean. Following the official docs [1] I did echo x11-wm/aquamarine-0.2.1 /etc/portage/profile/package.provided but it doesn't seem to help. I guess you are using heliodor or emerald as window-decorator. You can try to unset the kde use flag for the beryl ebuild which tries to pull in aquamarine. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] package.provided
On Tue, 8 May 2007 17:39:17 +0200 Daniel Pielmeier [EMAIL PROTECTED] wrote: I have x11-wm/beryl-0.2.1 installed on a stable system. One of its dependencies is ~x11-wm/aquamarine-0.2.1 which dies during compilation. This is fine with me because I installed beryl issuing: emerge --resume --skipfirst and it works OK. My problem is that portage wants to pull in aquamarine every time I execute: emerge -DuN world or emerge --depclean. Following the official docs [1] I did echo x11-wm/aquamarine-0.2.1 /etc/portage/profile/package.provided but it doesn't seem to help. I guess you are using heliodor or emerald as window-decorator. You can try to unset the kde use flag for the beryl ebuild which tries to pull in aquamarine. Thank you! Indeed I'm using heliodor and removing the kde USE flag did the work for me but the question (now just out of curiosity) still remains. -- Best regards, Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] package.provided
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Iliev wrote: Following the official docs [1] I did echo x11-wm/aquamarine-0.2.1 /etc/portage/profile/package.provided but it doesn't seem to help. The way that emerge currently behaves, that won't help if aquamarine is listed in /var/lib/portage/world. If you've unmerged aquamarine since then, it will have been removed from the world file. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) iD8DBQFGQNnP/ejvha5XGaMRAjXfAKCHfu6uaYAr/T2NYHydVpDSTEFBOACfchVb lwBIilmEpFH4I7311S/xziM= =C0bQ -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
proper use of package.provided (was: Re: [gentoo-user] package.provided)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: Jeremy Olexa wrote: Great, I knew there must be a solution for this issue. Thanks for interpreting the man page for me ;) Perhaps it could be more clear what site-specific overrides means but now I know. Thanks again. Could you suggest wording that would make it more clear to you? There's no rule saying the docs can't be fixed. =) Thanks, Donnie Donnie, My only suggestion would be to include an example. Neil's example was good enough for me. example: /etc/portage/profile/package.provided overrides /etc/make.profile/package.provided instead of: site-specific overrides - -- Jeremy Olexa ([EMAIL PROTECTED]) Office: EE/CS 1-201 CS/IT Systems Staff University of Minnesota -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEwEuIFN7pD9kMi/URAlEXAJ4gTxL5xMnqRpSHbBTVn7fJDELVwgCaA+ms 1Of61ktmztzFzAvwwB2409c= =RxEI -END PGP SIGNATURE- -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package.provided
On Sun, 16 Jul 2006 20:22:54 -0500, Jeremy Olexa wrote: Is there any other solution to the /etc/make.profile/package.provided file? As we all know the /usr/portage/ dir gets wiped of custom files on every sync. It seems kinda silly that there is a package.provided solution but it gets wiped every time, so is there any other way to accomplish the same thing on a more permanent term that I am not aware of? The portage man page does not suggest anything else. /etc/portage/profile overrides anything in /etc/make.profile, so use /etc/portage/profile/package.provided. This is covered in the portage man page /etc/portage/profile/ site-specific overrides of /etc/make.profile/ -- Neil Bothwick After a number of decimal places, nobody gives a damn. signature.asc Description: PGP signature
Re: [gentoo-user] package.provided
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Neil Bothwick wrote: On Sun, 16 Jul 2006 20:22:54 -0500, Jeremy Olexa wrote: Is there any other solution to the /etc/make.profile/package.provided file? As we all know the /usr/portage/ dir gets wiped of custom files on every sync. It seems kinda silly that there is a package.provided solution but it gets wiped every time, so is there any other way to accomplish the same thing on a more permanent term that I am not aware of? The portage man page does not suggest anything else. /etc/portage/profile overrides anything in /etc/make.profile, so use /etc/portage/profile/package.provided. This is covered in the portage man page /etc/portage/profile/ site-specific overrides of /etc/make.profile/ Great, I knew there must be a solution for this issue. Thanks for interpreting the man page for me ;) Perhaps it could be more clear what site-specific overrides means but now I know. Thanks again. - -- Jeremy Olexa ([EMAIL PROTECTED]) Office: EE/CS 1-201 CS/IT Systems Staff University of Minnesota -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEvGN4FN7pD9kMi/URAqzQAJ494WzMlj76m4wYB5zdr5mSyFt9dgCfaPpz XHuUxSHhMp2czQ8d9UEEctc= =eYDW -END PGP SIGNATURE- -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package.provided
Jeremy Olexa wrote: Great, I knew there must be a solution for this issue. Thanks for interpreting the man page for me ;) Perhaps it could be more clear what site-specific overrides means but now I know. Thanks again. Could you suggest wording that would make it more clear to you? There's no rule saying the docs can't be fixed. =) Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-user] package.provided
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Is there any other solution to the /etc/make.profile/package.provided file? As we all know the /usr/portage/ dir gets wiped of custom files on every sync. It seems kinda silly that there is a package.provided solution but it gets wiped every time, so is there any other way to accomplish the same thing on a more permanent term that I am not aware of? The portage man page does not suggest anything else. Thanks. - -- Jeremy Olexa ([EMAIL PROTECTED]) Office: EE/CS 1-201 CS/IT Systems Staff University of Minnesota -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEuuZtFN7pD9kMi/URAqWbAJ4s/AUJfMhlRIHFMFF9Y+klSqMhJgCfWL1g 48mF2vMh2M7YlWumepiIVSk= =PDsH -END PGP SIGNATURE- -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package.provided
Check out /etc/make.conf - that will override some settings. You aren't supposed to mess with the make.profile - it's a defalt that all else is based on. On Sunday July 16 2006 21:22, Jeremy Olexa wrote: Hi, Is there any other solution to the /etc/make.profile/package.provided file? As we all know the /usr/portage/ dir gets wiped of custom files on every sync. It seems kinda silly that there is a package.provided solution but it gets wiped every time, so is there any other way to accomplish the same thing on a more permanent term that I am not aware of? The portage man page does not suggest anything else. Thanks. -- Jeremy Olexa ([EMAIL PROTECTED]) Office: EE/CS 1-201 CS/IT Systems Staff University of Minnesota -- Brett I. Holcomb -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package.provided
On Sun, Jul 16, 2006 at 08:22:54PM -0500, Penguin Lover Jeremy Olexa squawked: Hi, Is there any other solution to the /etc/make.profile/package.provided file? As we all know the /usr/portage/ dir gets wiped of custom files on every sync. It seems kinda silly that there is a package.provided solution but it gets wiped every time, so is there any other way to accomplish the same thing on a more permanent term that I am not aware of? The portage man page does not suggest anything else. I've been wondering about that too. Perhaps that is what /etc/portage/profile is for? Per man portage: /etc/portage/profile/ site-specific overrides of /etc/make.profile/ W -- Confront a child, a puppy, and a kitten with a sudden danger; the child will turn instinctively for assistance, the puppy will grovel in abject submission. The kitten will brace its tiny body for a frantic resistance. ~Saki Sortir en Pantoufles: up 5 days, 8:17 -- gentoo-user@gentoo.org mailing list
[gentoo-user] package.provided syntax
I'm currently trying to get thru an emerge -vuD world but having various things crop up. Some I thought were handled long ago like this overlooking what is in package.provided: rsnapshot-1.2.2 bacula-1.48.5 cvs-emacs-24 The last two are fake versions so they would stay ahead of what ever comes into portage for a while. My understanding is that portage looks here, and if the version is newer it by passes these packages. So this should not happen: emerge -vuDp app-editors/emacs-cvs These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] app-editors/emacs-cvs-22.0.50-r1 [22.0.50] USE=X gif gtk jpeg nls png spell -Xaw3d -tiff 0 kB Oh, and why is `tiff' turned off (-tiff)? -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package.provided syntax
Harry Putnam wrote: in package.provided: cvs-emacs-24 [snip] emerge -vuDp app-editors/emacs-cvs Don't you see that cvs-emacs is not the same as emacs-cvs, or was this just a typo on your part? -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package.provided syntax
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Harry Putnam wrote: I'm currently trying to get thru an emerge -vuD world but having various things crop up. Some I thought were handled long ago like this overlooking what is in package.provided: rsnapshot-1.2.2 bacula-1.48.5 cvs-emacs-24 The example for package.provided syntax in `man portage` shows categories like this: app-backup/rsnapshot-1.2.2 app-backup/bacula-1.48.5 app-editors/emacs-cvs-24 And like Dave said, you have cvs-emacs rather than emacs-cvs. Zac The last two are fake versions so they would stay ahead of what ever comes into portage for a while. My understanding is that portage looks here, and if the version is newer it by passes these packages. So this should not happen: emerge -vuDp app-editors/emacs-cvs These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] app-editors/emacs-cvs-22.0.50-r1 [22.0.50] USE=X gif gtk jpeg nls png spell -Xaw3d -tiff 0 kB Oh, and why is `tiff' turned off (-tiff)? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFEDISR/ejvha5XGaMRAiiNAJ96sa0yTnYzsimB3MwzkgSaC5KeHQCeJaQt /siLLdvGc77aWlmKr4s+OxU= =7fXZ -END PGP SIGNATURE- -- gentoo-user@gentoo.org mailing list
[gentoo-user] package.provided location question
Hi, Generic question - why is package.provided located in /etc/make.profile instead of in /etc/portage? Won't l lose my edits when profile changes come along? It seems to me that if I take responsibility for a package, such as jack-audio-connection-kit, that I wouldn't want the system to take responsibility for it later on when a profile change comes along. package.provided is a great feature. I would have killed for this on my old Redhat systems. Thanks, Mark -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package.provided location question
On 10 Sep 2005, at 16:15, Mark Knecht wrote: Hi, Generic question - why is package.provided located in /etc/make.profile instead of in /etc/portage? Won't l lose my edits when profile changes come along? It seems to me that if I take responsibility for a package, such as jack-audio-connection-kit, that I wouldn't want the system to take responsibility for it later on when a profile change comes along. package.provided is a great feature. I would have killed for this on my old Redhat systems. Thanks, Mark Yes, if you keep package.provided in /etc/make.profile it will get overwritten at every sync. The proper place to put your overrides is in /etc/portage/profile, which took me a good while to figure out... Indeed it is rather nice :-) HTH, Chris -- Chris Boot [EMAIL PROTECTED] http://www.bootc.net/ smime.p7s Description: S/MIME cryptographic signature
Re: [gentoo-user] package.provided location question
On 9/10/05, Chris Boot [EMAIL PROTECTED] wrote: On 10 Sep 2005, at 16:15, Mark Knecht wrote: Hi, Generic question - why is package.provided located in /etc/make.profile instead of in /etc/portage? Won't l lose my edits when profile changes come along? It seems to me that if I take responsibility for a package, such as jack-audio-connection-kit, that I wouldn't want the system to take responsibility for it later on when a profile change comes along. package.provided is a great feature. I would have killed for this on my old Redhat systems. Thanks, Mark Yes, if you keep package.provided in /etc/make.profile it will get overwritten at every sync. The proper place to put your overrides is in /etc/portage/profile, which took me a good while to figure out... Indeed it is rather nice :-) HTH, Chris Hi Chris, Thanks. That seems to work and is indeed a much better place to put it. I did not see that in the man pages (is it there?) so I appreciate the pointer. Cheers, Mark -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package.provided location question
On Sat, 10 Sep 2005 11:50:24 -0700, Mark Knecht wrote: Thanks. That seems to work and is indeed a much better place to put it. I did not see that in the man pages (is it there?) so I appreciate the pointer. It's buried in the portage man page. Basically, what you put in /etc/portage/profile overrules the settings from /etc/make.profile. -- Neil Bothwick It might look like I'm doing nothing, but at the cellular level I'm really quite busy. pgpIBMPuIIc8K.pgp Description: PGP signature
Re: [gentoo-user] package.provided location question
On 9/10/05, Neil Bothwick [EMAIL PROTECTED] wrote: On Sat, 10 Sep 2005 11:50:24 -0700, Mark Knecht wrote: Thanks. That seems to work and is indeed a much better place to put it. I did not see that in the man pages (is it there?) so I appreciate the pointer. It's buried in the portage man page. Basically, what you put in /etc/portage/profile overrules the settings from /etc/make.profile. It's a great feature and I'm glad my question wasn't brain dead. It made sense that my changes go somewhere personal. I just didn't see it. It all works great now. Thanks! - Mark -- gentoo-user@gentoo.org mailing list
