William L. Thomson Jr. posted on Mon, 17 Oct 2016 01:36:33 -0400 as excerpted:
> On Monday, October 17, 2016 4:37:50 AM EDT Duncan wrote: >> William L. Thomson Jr. posted on Sun, 16 Oct 2016 18:30:44 -0400 as >> >> excerpted: >> > Then how would you test that against non official? You cannot install >> > the same package twice at the same time with different USE flags. You >> > can't even make binaries easily of the same package with different >> > USE flags. The previous binary will get overwritten. >> >> AFAIK, with current portage now you can have multiple binaries of the >> same package, with different USE flags or built with different CFLAGS >> or whatever, tho the feature's off by default. > > Very nice, any chance that also includes generated binaries? > > I make binaries for other systems to merge allot (binpkg). It sucks to > have them clobbered with different USE flags. I always wanted to be able > to keep the various binaries with different USE flags. Like some systems > are hardened others not, so recompile gcc vs having 2. > > Not sure if that is a step in that direction, but it is a cool feature > just the same. Allows for further testing. I was talking about binpkg (not actually installing, that is qmerging, multiple different versions of the package). However, now that you asked the question, I can see that what I wrote was somewhat ambiguous. Again, I've not followed this extremely closely as real life has been crowding out much of my gentooing recently (I bought a house and moved, was in a hotel temporarily for a few months in the mean time and am still rather bare-bones in the new place), but the general idea is pretty much exactly as you suggest. With the appropriate option set, portage will bump a sequence number on the binpkg files when the same version is remerged instead of replacing the old binpkg. There's infrastructure for tracking multiple binpkgs of the same version as well, and portage should be smart enough to match USE flags at least, selecting an existing binpkg that matches where possible, and building a new one to add to the collection when there's not an existing match. I'm not likely to use it for that, but I've been going to look into the feature and see if it could help managing -9999 live-vcs packages at some point... when I get the time. The biggest problem with live-vcs packages ATM is the possibility of something breaking and not having a good record of your commit-build history, making bisecting more difficult than it should be. This feature could conceivably help not only with that, but in allowing binpkg remerge of the last good build when something breaks, too, thus shortcutting the actual rebuild when there's not time to bisect and you just want to get a working package back again. But that multi-binpkg should now be possible with current ~arch portage is about all I know, ATM, due to lack of time to do more than skim the proposed and ultimately approved commits as they're posted to the portage- dev list (which I follow via gmane, as I do all my lists including this one). I don't even know what to toggle to turn it on as I've not been following that closely. But I imagine it could be awhile still until it's in stale for those that don't run ~arch... -- 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
