[gentoo-dev] Re: Package file name requirement for binary ebuilds

[Duncan]

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