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