| 1 |
On 12/24/2014 04:01 AM, vivo75@×××××.com wrote: |
| 2 |
> Il 24/12/2014 09:13, Zac Medico ha scritto: |
| 3 |
>>> I like this (and it has been a long time coming). What format are we |
| 4 |
>>>> going to store the metadata of the use flag combinations and the rest? |
| 5 |
>> The current approach is to store the data in an xpak segment that is |
| 6 |
>> appended to the end of the tbz2 file. The $PKGDIR/Packages files serves |
| 7 |
>> as a cache for the essential parts of the xpak data that are used in |
| 8 |
>> dependency calculations. |
| 9 |
>> |
| 10 |
> I'd like to see the xpak data being put in it's own file at the |
| 11 |
> _beginning_ of the tar file. |
| 12 |
> |
| 13 |
> tar -Jcf \ |
| 14 |
> ${PKGDIR}/${CATEGORY}/${PN}/${PF}-${COUNTER}.xpak \ |
| 15 |
> tmp/${CATEGORY}:${PN}:${PF}-${COUNTER}.xpak \ |
| 16 |
> *all_the_other_stuff* |
| 17 |
> |
| 18 |
> this way reading it could be faster on some media and filesystem and it |
| 19 |
> would not deviate from the standard tar. |
| 20 |
|
| 21 |
There wouldn't be any benefit, because the data is practically always |
| 22 |
read from the $PKGDIR/Packages cache anyway. The cache is generated when |
| 23 |
the package is built, and the rate-limiting step there is the building |
| 24 |
of the package. |
| 25 |
|
| 26 |
> Being in /tmp/ is only for commodity but the place is debatable. |
| 27 |
> Instead the fact it _must_ be the first file it's not, in a sequential |
| 28 |
> archive file like tar some things depend on it. |
| 29 |
|
| 30 |
With the current approach, the xpak segment is not part of the tar file. |
| 31 |
The tar file is compressed, and the xpak segment is appended to the end |
| 32 |
of the resulting bzip2 file. |
| 33 |
|
| 34 |
> seem to be the right time to do the change, since tool need to be |
| 35 |
> rewritten anyway, but I'll leave to you analyze the fallout of this change. |
| 36 |
|
| 37 |
There will be zero benefits from doing that. |
| 38 |
-- |
| 39 |
Thanks, |
| 40 |
Zac |
Archives