Re: [gentoo-portage-dev] [RFC] New file layout for PKGDIR and binhosts

[Zac Medico <zmedico@gentoo.org>]

On 12/27/2014 06:25 AM, Rick "Zero_Chaos" Farina wrote:
> On 12/23/14 20:51, Zac Medico wrote:
>> Hi,
>>
>> As discussed in bug 150031 [1], it would be useful if PKGDIR could
>> accommodate multiple binary packages built from the same source ebuild.
>> Use cases for preserving multiple builds typically involve supporting
>> multiple clients (with partially compatible configurations) from a
>> single unified binhost. In this context, some of the reasons to retain
>> multiple builds are:
>>
>> * Different USE flag combinations enabled (--newuse/--binpkg-respect-use
>> needed)
>>
>> * Different versions of installed dependencies (EAPI 5 slot := operators
>> needed)
>>
>> * Different repositories/overlays, with variance in the time of the last
>> sync (--changed-deps/--binpkg-changed-deps needed if dependencies change
>> due to eclass changes or ebuild modifications without revbump)
> 
> I'm not saying don't take this into account, but in reality, this isn't
> a problem we should have to deal with.

Who is we? How do you know that whatever practices you use will also be
utilized by everyone else out there?

> if users want to rely on binpkgs
> they should be syncing to the same rev the binhost used to generate
> them.  it's a reasonably trivial task to do this, even as simple as
> daily webrsync or something.

The --changed-deps/--binpkg-changed-deps are also useful for the same
reason that emerge --dynamic-deps is enabled by default:

* On the binhost server side, --changed-deps is an easy way to rebuild
packages so the resulting binary packages have the latest deps, which
may be necessary in order for the dependencies to be *satisfiable*.

* On the binhost client side, --binpkg-changed-deps can be used to
reject binary packages that haven't been rebuilt with the latest
dependency specifications, avoiding inconsistent dependencies that may
not be *satisfiable*.

Sure, the --binpkg-changed-deps thing may not be needed for whatever
limited use cases you are thinking of, but lets not force the same
limits on everyone else.

> To handle users with a different class or
> ebuild version will prove difficult I believe, and worse, it will make
> possibly dozens of extra binpkg revs for basically no reason.

As discussed the above, these "extra binpkg revs" may be needed in order
for the dependencies to be *satisfiable*. The cost of rebuilding
packages can be considered negligible in comparison to the time that
people would otherwise have to spend in order to manually resolve issues
involving dependencies that are unsatisfiable.
-- 
Thanks,
Zac