From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 5638C1389E2 for ; Sat, 27 Dec 2014 19:26:45 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 18D6DE07E1; Sat, 27 Dec 2014 19:26:44 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5DDA2E07D6 for ; Sat, 27 Dec 2014 19:26:43 +0000 (UTC) Received: from [192.168.1.105] (cblmdm134-228-136-191.buckeyecom.net [134.228.136.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zerochaos) by smtp.gentoo.org (Postfix) with ESMTPSA id 3A40F33FFDF for ; Sat, 27 Dec 2014 19:26:39 +0000 (UTC) Message-ID: <549EC172.80004@gentoo.org> Date: Sat, 27 Dec 2014 09:25:54 -0500 From: "Rick \"Zero_Chaos\" Farina" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@lists.gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-portage-dev@lists.gentoo.org Subject: Re: [gentoo-portage-dev] [RFC] New file layout for PKGDIR and binhosts References: <549A1C31.8040500@gentoo.org> In-Reply-To: <549A1C31.8040500@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NvXdjoJi0nXlKa6VIMapJidWq8U0N3O9P" X-Archives-Salt: f342a6d3-5626-4fc0-8bfb-ab2e07139f38 X-Archives-Hash: 1279082d0abac6ad3062d2847f488166 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NvXdjoJi0nXlKa6VIMapJidWq8U0N3O9P Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/23/14 20:51, Zac Medico wrote: > Hi, >=20 > As discussed in bug 150031 [1], it would be useful if PKGDIR could > accommodate multiple binary packages built from the same source ebuild.= > Use cases for preserving multiple builds typically involve supporting > multiple clients (with partially compatible configurations) from a > single unified binhost. In this context, some of the reasons to retain > multiple builds are: >=20 > * Different USE flag combinations enabled (--newuse/--binpkg-respect-us= e > needed) >=20 > * Different versions of installed dependencies (EAPI 5 slot :=3D operat= ors > needed) >=20 > * Different repositories/overlays, with variance in the time of the las= t > sync (--changed-deps/--binpkg-changed-deps needed if dependencies chang= e > due to eclass changes or ebuild modifications without revbump) I'm not saying don't take this into account, but in reality, this isn't a problem we should have to deal with. if users want to rely on binpkgs they should be syncing to the same rev the binhost used to generate them. it's a reasonably trivial task to do this, even as simple as daily webrsync or something. To handle users with a different class or ebuild version will prove difficult I believe, and worse, it will make possibly dozens of extra binpkg revs for basically no reason. -Zero_Chaos PS> This is so exciting.... >=20 > Given the above variety of reasons to retain previous builds, a simple > counter (1, 2, 3,...) seems like a reasonable means to generate unique > file names. >=20 > In order to avoid having too many files in a directory, we can use a > separate directory for each ${CATEGORY}/${PN}, like we do for the sourc= e > ebuild repositories. >=20 > In order to avoid having to deal with multiple file extensions for > different compression types, we can simply use .xpak for the file > extension [2], since that's the name of the format that we use to appen= d > metadata to our existing tbz2 files. We can simply probe the first few > bytes of the file in order to determine the compression type: >=20 > gzip: 1f 8b > bzip2: 42 5a 68 39 > xz: fd 37 7a 58 5a 00 >=20 > Users will be able change their compression settings at any time, but > the .xpak file extension will remain constant regardless of that > setting. It won't matter if they have a mixture of files compressed wit= h > different compressors. >=20 > A tool like eclean-pkg will be needed to clean up old binary packages > based on user preferences. We might also provide a variety of on-the-fl= y > garbage collection settings. >=20 > Based on the above discussion, the location of any particular binary > package can be expressed as follows: >=20 > ${PKGDIR}/${CATEGORY}/${PN}/${PF}-${COUNTER}.xpak >=20 > The existing format of the ${PKGDIR}/Packages index will work fine, > since it allows each package to specify a PATH attribute which > corresponds to the path of the file relative to the base directory. If > the .xpak files use bzip2 compression, it will even be compatible with > existing clients (though they won't be able to intelligently choose > between multiple packages of the same version). If all the packages of = a > given version are ordered by ${COUNTER}, then existing clients will > simply download the latest build. >=20 > [1] https://bugs.gentoo.org/show_bug.cgi?id=3D150031 > [2] http://dev.gentoo.org/~zmedico/portage/doc/man/xpak.5.html >=20 --NvXdjoJi0nXlKa6VIMapJidWq8U0N3O9P Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUnsF6AAoJEKXdFCfdEflKMZMP/0pm53TPMn23phYxBHuIwChV NkWobgsYEg8k8GoHVgTJJNuRpW58y1pSpQFD9gq9uYwP88NIuyvHUaR2CbQJWUvQ +Jp7t2iieL/M6W36RZeygYB7kW7KMKgTYVMN0/oZMfRVxkuby4vA49cQToQMVGPp ia7REQf1ws6yaqzGrBz3QDyrKoQCTp3zVJV1H7rTtMJqRZOrSOZDos38hEiOJ/vS GCxHDSFL+Cq1+9uugQdgBY5/ZYfwpfwJ8PcUfyDZGFXszKfzGcxpN+P4mZ9ThtU5 wJwoX5HCtv/XkCHL7h9uOn4DjenRp4z+eXx/6q5V7RDbQqyiUKKgCl9IS3BQHg+h mA4WRAw4NRddDIHWdHRmW0b3ub3UaB/YxgWLfWOl1ksE+XPaLPrB+tNy2AgYXJGN IjZk12nCsYCNKfxKu5HNPi83l02W0fW19nLxj1zAGAxXyHbC3flH3lPjYAu3IDve j+guEE4prXxiMXo9VGLEp//atOOiIrZlmuEduMeOPG7vrRBIL/9G2pBGTJJxrPk4 K9EQDphXoUBnwOcNX4JxkH4E+RH1K78Inv0k3fmuVbwKyxvhYOuCl1QgFJAx2qCM SqNdOuqh2OkHvwmVtBk5p9TrQAn2U9U367RftGl2/7s6fCbLVSKYEKC9jajA/ErJ JdT8QZdqA2vVXyDsxaog =c3sa -----END PGP SIGNATURE----- --NvXdjoJi0nXlKa6VIMapJidWq8U0N3O9P--