On 21 January 2015 at 22:44, Rich Freeman <ri...@gentoo.org> wrote: > On Wed, Jan 21, 2015 at 9:00 AM, Sam Bishop <sam@cygnus.email> wrote: >> >> I don't see why it can't be all the combinations, the issue is >> storage, and the storage costs could be a lot lower than expected >> given how hard it is to guess. > > I don't believe that binpkg filenames contain the use flag settings, > and I'm not sure that given multiple copies of a binpkg with different > filenames portage goes through them and figures out which ones are > which. This isn't an area I have looked into seriously. However, it > obviously would be a blocker for getting what you propose to work, > even theoretically. >
I'll quote from the binpkg docs: >> Next to these, portage will check if the binary package is built using the >> same USE flags as expected on the client. If a package is built with a >> different USE flag combination, portage will either ignore the binary >> package (and use source-based build) or fail, depending on the options >> passed on to emerge So I'm fairly sure that implies they can coexist based on the directory structure. - http://wiki.gentoo.org/wiki/Binary_package_guide#The_PKGDIR_layout One big concern would be having a HUGE Packages metadata file and making the look up too slow. I'm not sure how big that file could get before things became an issue. http://wiki.gentoo.org/wiki/Binary_package_guide#Pulling_packages_from_a_binary_package_host > > I don't really see the value in having EVERY combination of use flags > on call though. > > Practically speaking I doubt this could be done. You're talking about > a LOT of combinations. > > However, I think it would be very useful to have a binpkg repository > all the same. Perhaps have one for each of a few common profiles with > the default flags. That alone would be a significant undertaking. > > Just about everybody who has talked about running Gentoo in a > datacenter has set up a binpkg repository. They may very well deviate > from the default USE flags, but for the most part they try to keep > their systems identical. They would build updates as binpkg, install > to a test system, and after testing deploy them to production and that > would of course go quickly. > > I have a script I use to build binpkg nightly for the day's updates. > That lets me review updates and deploy them quickly. Any rebuilds/etc > still take time, but the bulk of my updates are very fast this way > with minimal time spent staring at the screen. This would be another > route to take if your really did need highly varied deployments. > > -- > Rich >
