Re: [gentoo-portage-dev] custom profiles?
On 03/13/2015 05:08 AM, Joakim Tjernlund wrote: On Thu, 2015-03-12 at 17:51 -0700, Zac Medico wrote: On 03/12/2015 02:43 PM, Joakim Tjernlund wrote: Why is --dynamic-deps=y default? This feels like lying about your true deps, I am probably missing something here, an example would be great:) It's a legacy behavior, since portage has always behaved this way, and ebuild developers have relied upon it (resulting in broken dependency calculations without it). Here is odd difference: emerge --dynamic-deps=n changed-deps=y -a1 vanilla-sources ... Nothing to merge That's normal, because --changed-deps implies --selective (a number of options do this). If you add -- selective=n to the above command, you'll get the same result regardless of the --changed-deps option. I just did a sync and emerge -aNDu --dynamic-deps=n --changed-deps=y --selective=n world and again portage wanted to rebuild 150 pkgs. --selective=n seems to be the culprit, should I expect this from --selective=n ? Yes --selective=n is the opposite of --noreplace, so for the above command, it will rebuild everything in /var/lib/portage/world. -- Thanks, Zac
Re: [gentoo-portage-dev] custom profiles?
On Thu, 2015-03-12 at 17:51 -0700, Zac Medico wrote: On 03/12/2015 02:43 PM, Joakim Tjernlund wrote: Why is --dynamic-deps=y default? This feels like lying about your true deps, I am probably missing something here, an example would be great:) It's a legacy behavior, since portage has always behaved this way, and ebuild developers have relied upon it (resulting in broken dependency calculations without it). Here is odd difference: emerge --dynamic-deps=n changed-deps=y -a1 vanilla-sources ... Nothing to merge That's normal, because --changed-deps implies --selective (a number of options do this). If you add -- selective=n to the above command, you'll get the same result regardless of the --changed-deps option. Thanks, now it works as before. Is there something else I should look out for? Behaviour that has changed? Jocke
[gentoo-portage-dev] Re: running ebuild in src tree
Joakim Tjernlund posted on Thu, 12 Mar 2015 17:26:59 + as excerpted: No, there can be no copy of sources for what I want. It just gets in the way having to do that. ?? Copying to tmpfs is copying to memory, and copying to memory in /some/ form must occur in ordered to operate on the files at all, that is, with any build at all, so I don't see the problem, at least if you're working on a machine with say 2+ gigs RAM. (There might be problems on a half-gig RAM machine, but that's not particularly appropriate as a developer machine in any case, these days, unless you're talking embedded, which you didn't mention.) But of course, gentoo/portage lets you do it your way too, as demonstrated by the hacks you posted. =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-portage-dev] Re: running ebuild in src tree
On Fri, 2015-03-13 at 06:32 +, Duncan wrote: Joakim Tjernlund posted on Thu, 12 Mar 2015 17:26:59 + as excerpted: No, there can be no copy of sources for what I want. It just gets in the way having to do that. ?? Copying to tmpfs is copying to memory, and copying to memory in /some/ form must occur in ordered to operate on the files at all, that is, with any build at all, so I don't see the problem, at least if you're working on a machine with say 2+ gigs RAM. (There might be problems on a half-gig RAM machine, but that's not particularly appropriate as a developer machine in any case, these days, unless you're talking embedded, which you didn't mention.) But of course, gentoo/portage lets you do it your way too, as demonstrated by the hacks you posted. =:^) When you are developing SW you do the edit/build cycle often and it is really annoying to copy a big src tree, rebuild everything (as timestamps, deps changes), move to another src to do any debugging etc. Try it on your own development by just copying you src tree every time you want to build, you get very tired of it real soon :) Don't get me wrong, portage is a wounderful pkg mgr, I just want to extend its use to be more helpful during development too, without having to do really ugly hacks like I showed you. Jocke
[gentoo-portage-dev] Re: running ebuild in src tree
Joakim Tjernlund posted on Fri, 13 Mar 2015 08:13:01 + as excerpted: When you are developing SW you do the edit/build cycle often and it is really annoying to copy a big src tree, rebuild everything (as timestamps, deps changes), move to another src to do any debugging etc. Try it on your own development by just copying you src tree every time you want to build, you get very tired of it real soon :) That's what ccache is for. For some time I was following live-kde (tho I'm not ATM as kf5 wasn't working for me yet, last I tried, and kde4 development is pretty much dead, now) and doing rebuilds several times a week, so I know what it's like. =:^) But I do get your point, now. Still, unless it's something like firefox, while I used to get irritated with the extra build time back when I was running a dual-core, a quad- core improved that, and with my current 6-core bulldozer-1 (fx6100), PORTAGE_TMPDIR on tmpfs, and the system and ccache on ssd, most of the time I just let it do the rebuild. It's really not worth the trouble worrying about it any more, particularly when I can be doing other stuff while it builds. But you're right, being able to build right in an existing git clone without the hassle of hacks such as you posted, and even configuring live- ebuilds to do just that with say a variable setting that could be set by a package.env pointer, would be nice indeed. Local hacking on such live- build packages would be quite a bit easier, that way. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-portage-dev] custom profiles?
On Thu, 2015-03-12 at 17:51 -0700, Zac Medico wrote: On 03/12/2015 02:43 PM, Joakim Tjernlund wrote: Why is --dynamic-deps=y default? This feels like lying about your true deps, I am probably missing something here, an example would be great:) It's a legacy behavior, since portage has always behaved this way, and ebuild developers have relied upon it (resulting in broken dependency calculations without it). Here is odd difference: emerge --dynamic-deps=n changed-deps=y -a1 vanilla-sources ... Nothing to merge That's normal, because --changed-deps implies --selective (a number of options do this). If you add -- selective=n to the above command, you'll get the same result regardless of the --changed-deps option. I just did a sync and emerge -aNDu --dynamic-deps=n --changed-deps=y --selective=n world and again portage wanted to rebuild 150 pkgs. --selective=n seems to be the culprit, should I expect this from --selective=n ? Jocke
