| 1 |
Hi, |
| 2 |
|
| 3 |
As discussed in bug 150031 [1], it would be useful if PKGDIR could |
| 4 |
accommodate multiple binary packages built from the same source ebuild. |
| 5 |
Use cases for preserving multiple builds typically involve supporting |
| 6 |
multiple clients (with partially compatible configurations) from a |
| 7 |
single unified binhost. In this context, some of the reasons to retain |
| 8 |
multiple builds are: |
| 9 |
|
| 10 |
* Different USE flag combinations enabled (--newuse/--binpkg-respect-use |
| 11 |
needed) |
| 12 |
|
| 13 |
* Different versions of installed dependencies (EAPI 5 slot := operators |
| 14 |
needed) |
| 15 |
|
| 16 |
* Different repositories/overlays, with variance in the time of the last |
| 17 |
sync (--changed-deps/--binpkg-changed-deps needed if dependencies change |
| 18 |
due to eclass changes or ebuild modifications without revbump) |
| 19 |
|
| 20 |
Given the above variety of reasons to retain previous builds, a simple |
| 21 |
counter (1, 2, 3,...) seems like a reasonable means to generate unique |
| 22 |
file names. |
| 23 |
|
| 24 |
In order to avoid having too many files in a directory, we can use a |
| 25 |
separate directory for each ${CATEGORY}/${PN}, like we do for the source |
| 26 |
ebuild repositories. |
| 27 |
|
| 28 |
In order to avoid having to deal with multiple file extensions for |
| 29 |
different compression types, we can simply use .xpak for the file |
| 30 |
extension [2], since that's the name of the format that we use to append |
| 31 |
metadata to our existing tbz2 files. We can simply probe the first few |
| 32 |
bytes of the file in order to determine the compression type: |
| 33 |
|
| 34 |
gzip: 1f 8b |
| 35 |
bzip2: 42 5a 68 39 |
| 36 |
xz: fd 37 7a 58 5a 00 |
| 37 |
|
| 38 |
Users will be able change their compression settings at any time, but |
| 39 |
the .xpak file extension will remain constant regardless of that |
| 40 |
setting. It won't matter if they have a mixture of files compressed with |
| 41 |
different compressors. |
| 42 |
|
| 43 |
A tool like eclean-pkg will be needed to clean up old binary packages |
| 44 |
based on user preferences. We might also provide a variety of on-the-fly |
| 45 |
garbage collection settings. |
| 46 |
|
| 47 |
Based on the above discussion, the location of any particular binary |
| 48 |
package can be expressed as follows: |
| 49 |
|
| 50 |
${PKGDIR}/${CATEGORY}/${PN}/${PF}-${COUNTER}.xpak |
| 51 |
|
| 52 |
The existing format of the ${PKGDIR}/Packages index will work fine, |
| 53 |
since it allows each package to specify a PATH attribute which |
| 54 |
corresponds to the path of the file relative to the base directory. If |
| 55 |
the .xpak files use bzip2 compression, it will even be compatible with |
| 56 |
existing clients (though they won't be able to intelligently choose |
| 57 |
between multiple packages of the same version). If all the packages of a |
| 58 |
given version are ordered by ${COUNTER}, then existing clients will |
| 59 |
simply download the latest build. |
| 60 |
|
| 61 |
[1] https://bugs.gentoo.org/show_bug.cgi?id=150031 |
| 62 |
[2] http://dev.gentoo.org/~zmedico/portage/doc/man/xpak.5.html |
| 63 |
-- |
| 64 |
Thanks, |
| 65 |
Zac |
Archives