| 1 |
I don't think I would have realized this implementation myself. Is this |
| 2 |
xpak piggybacking documented somewhere?Can you refer me? |
| 3 |
BTW: |
| 4 |
amit0 Installation # man xpak |
| 5 |
No manual entry for xpak |
| 6 |
amit0 Installation # man 5 xpak |
| 7 |
No entry for xpak in section 5 of the manual |
| 8 |
amit0 Installation # eix -S xpak |
| 9 |
No matches found. |
| 10 |
|
| 11 |
Amit |
| 12 |
|
| 13 |
Zac Medico wrote: |
| 14 |
> Amit Dor-Shifer wrote: |
| 15 |
> > When you say ut checks CHOST/keywording, where are those definitions |
| 16 |
> > stored for the binary pkg? |
| 17 |
> |
| 18 |
> It's appended to the tail end of the tbz2, in xpak format (see `man |
| 19 |
> 5 xpak`). |
| 20 |
> |
| 21 |
> > I see one instance of CHOST in the 'Packages' index on the BINHOST. Is |
| 22 |
> > that the variable emerge is comparing against? If not, where is it? the |
| 23 |
> > tbz itself holds just the binaries. |
| 24 |
> |
| 25 |
> Yes, for remote packages, the Package index contains equivalent data |
| 26 |
> to the actual xpak segments from the remote packages. The CHOST for |
| 27 |
> individual packages is only shown in cases when it differs from the |
| 28 |
> CHOST in the header of the Packages file. |
| 29 |
> |
| 30 |
> > Manually modifying a/m CHOST to 'ppc' didn't stop emerge from |
| 31 |
> > successfully merging a package on an amd64 target (I've removed |
| 32 |
> > /usr/portage/packages from target before emerging). |
| 33 |
> |
| 34 |
> The CHOST from your local configuration (typically from make.conf or |
| 35 |
> inherited from your profile) is compared to the CHOST of the binary |
| 36 |
> package. You can also use ACCEPT_CHOSTS if you want to accept more |
| 37 |
> than one CHOST (see `man 5 make.conf`). |
Archives