| 1 |
On Thu, 22 Jan 2015 16:43:32 +0800, Sam Bishop wrote: |
| 2 |
|
| 3 |
> I'll quote from the binpkg docs: |
| 4 |
> >> Next to these, portage will check if the binary package is built |
| 5 |
> >> using the same USE flags as expected on the client. If a package is |
| 6 |
> >> built with a different USE flag combination, portage will either |
| 7 |
> >> ignore the binary package (and use source-based build) or fail, |
| 8 |
> >> depending on the options passed on to emerge |
| 9 |
> |
| 10 |
> So I'm fairly sure that implies they can coexist based on the |
| 11 |
> directory structure. - |
| 12 |
> http://wiki.gentoo.org/wiki/Binary_package_guide#The_PKGDIR_layout |
| 13 |
|
| 14 |
The package name is the same as the ebuild name but with a .tbz2 |
| 15 |
extension, so how could portage cope with multiple variants with |
| 16 |
different USE flags when there is only one name? There can be only one |
| 17 |
package per ebuild and either the USE flags match exactly or they do not. |
| 18 |
|
| 19 |
You could get away with this with a limited set of profiles by having a |
| 20 |
different $PKGDIR for each profile but to do it with random combinations |
| 21 |
would require some sort of middleware to handle the requests and place |
| 22 |
the specified packages where portage expects to find them. |
| 23 |
|
| 24 |
I think the check for USE flags is done using the IUSE and USE settings |
| 25 |
in the package metadata, so even if a USE flag you don't use is added to |
| 26 |
an ebuild, the package will no longer match. ISTR having to hack metadata |
| 27 |
in /var/db in the past to avoid a rebuild of *Office. |
| 28 |
|
| 29 |
|
| 30 |
-- |
| 31 |
Neil Bothwick |
| 32 |
|
| 33 |
When companies ship Styrofoam, what do they pack it in? |
Archives