[gentoo-portage-dev] Exporting basic emerge/portage functionality in an API
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I think, this is already somewhere on the agenda of portage (perhaps with a low priority ;)), but I nevertheless wanted to ask for the possibility to have as much of emerge's functionality exported in an API as possible =). The reason behind this is, that for Portato (this GUI thingy ;)), I have to re-implement lots of things that portage does (update functionality, parts of dep-string parsing etc). This is kind of sisyphean, because one has to: - - notice/detect subtle changes (esp. the updating process often changes unnoticed in small points) - - support tons of portage versions Especially with larger bumps (2.1.1 -> 2.1.2; -> 2.2) there are lots of things breaking and showing another behavior. In the sum, this work takes quite a large part of the whole development process ... though showing no results for the user ;) Thus, it would be really great, if I only had to use an API (which might change over time - but API changes are easier to track and to work around). Perhaps - as you currently seem to be restructuring the whole thing - you can bundle some things and export them :). I bet there are more people out there besides me, that use or want to use the portage API and would be thankful, when they don't have to reinvent things :) Else - thank you guys for your great work :). It's very great to see portage's evolution over the last months. Regards, René -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiM4ToACgkQ4UOg/zhYFuBx8gCeMU+pZht4rosLNBU32YlSAex3 LyYAnRqVLpguj4i9ZHAcbQEYtTmvSNY+ =F398 -END PGP SIGNATURE-
Re: [gentoo-portage-dev] portage-2.2-rc3 parallel merges quit being parallel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan schrieb: > Also, a little monitoring utility that could be run in another terminal > and just list and update all the currently merging packages, and any that > had failed to merge, so I could take a look at them while the system is > still working on the rest, would be quite useful. A very basic thingy: watch qlop -cC qlop is part of portage-utils. And it seems to only work correctly here, when run as root :) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiM2zoACgkQ4UOg/zhYFuBQwQCeOPut3WtWXQYZuvpRuf0HFqNk r4wAn3JUVV3HWb/OYooBTNxz5mqb9Skx =Wdte -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH] Repoman subversion support
On 24-07-2008 17:38:51 +0200, Arfrever Frehtes Taifersar Arahesis wrote: > `svn list` returns only files which actually exist in the repository. It > doesn't check working copy. You should use `svn st`. Ok, you're right. But svn status simply sucks: [usr/portage/eclass] % touch x11.eclass.rej [usr/portage/eclass] % svn status ? files [usr/portage/eclass] % In other words, it auto-ignores stuff that really causes the messed up manifests if someone isn't paying attention. IIRC this ignorance isn't limited to .rej, but also other extentions, such as the trailing ~, which some editors leave behind. I guess we need to use --no-ignore, and then also recognise the "I" entries. Bah. -- Fabian Groffen Gentoo on a different level
[gentoo-portage-dev] Re: portage-2.2-rc3 parallel merges quit being parallel
Marius Mauch <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sun, 27 Jul 2008 03:32:10 +0200: > I did some benchmarking a while ago with different combinations of -j > and -l in MAKEOPTS, using the kernel as testcase, and IIRC the fastest > builds were around -l6.0 (on a dual-core system) and high (or unlimited) > values for -j FWIW... My experience suggests that there's some sort of race condition with the job count. I was getting occasional very irritating errors to the effect of "Job count is 17, should be 16" (or possibly the reverse), that would terminate the build. Rerunning it wouldn't trigger the problem again. By setting unlimited jobs (-j with no appended number), I avoided whatever it was, or at least haven't seen it since. I don't know enough about make's parallel job processing (OK, I simply know that it normally works, which makes it irritating when it doesn't) to have the foggiest what that was all about, except to assume it had to be some sort of race condition on the job counter. Has anyone else seen similar? Anyway, that's why I ultimately ended up with -j -lX, using the -lX part to do the limiting. With the previous simple job-at-a-time emerging, the few cases where -lX wasn't honored and therefore wasn't limiting wasn't a problem. Of course, there's some adjusting to be done now. =8^) But it's for a good reason! =8^) (I've already decided that --jobs=10 is going to need changed, I'm intuiting it needs to go up, but it's possible I need to lower it. More experimentation is necessary! =8^) -- 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
