<?xml version="1.0" encoding="utf-8"?> 
<rss version="2.0">
 <channel>
  <title>XGQT's blog: Posts tagged 'binary packages'</title>
  <description>XGQT's blog: Posts tagged 'binary packages'</description>
  <link>https://xgqt.gitlab.io/blog/tags/binary-packages.html</link>
  <lastBuildDate>Thu, 23 Mar 2023 08:01:04 UT</lastBuildDate>
  <pubDate>Thu, 23 Mar 2023 08:01:04 UT</pubDate>
  <ttl>1800</ttl>
  <item>
   <title>Binary packages in Gentoo</title>
   <link>https://xgqt.gitlab.io/blog/posts/2023/03/23/binary-packages-in-gentoo/?utm_source=binary-packages&amp;utm_medium=RSS</link>
   <guid isPermaLink="false">urn:https-xgqt-gitlab-io:-blog-posts-2023-03-23-binary-packages-in-gentoo</guid>
   <pubDate>Thu, 23 Mar 2023 08:01:04 UT</pubDate>
   <author>Maciej Barć</author>
   <description>
&lt;h1 id="binpkgs-generated-by-user"&gt;Binpkgs generated by user&lt;/h1&gt;

&lt;p&gt;The binary packages generated by user can have architecture-specific optimizations because they are generated after they were compiled by the host Portage installation.&lt;/p&gt;

&lt;p&gt;In addition binpkgs are generated from ebuilds so if there is a 
 &lt;u&gt;USE&lt;/u&gt; flag incompatibility on the consumer system then the binpkg will not be installed on the host and Portage will fall back to 
 &lt;u&gt;from-source&lt;/u&gt; compilation.&lt;/p&gt;

&lt;p&gt;Those binary packages can use two formats: &lt;a href="https://wiki.gentoo.org/wiki/Binary_package_guide#XPAK_format"&gt;XPAK&lt;/a&gt; and &lt;a href="https://www.gentoo.org/glep/glep-0078.html"&gt;GPKG&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;XPAK had many issues and is getting superseded by the GPKG format. Beware of upcoming GPKG transition and if you &lt;strong&gt;must&lt;/strong&gt; use XPAKs then you should explicitly enable it in your system&amp;rsquo;s Portage configuration.&lt;/p&gt;

&lt;p&gt;To host a binary package distribution server see the &lt;a href="https://wiki.gentoo.org/wiki/Binary_package_guide"&gt;Binary package guide&lt;/a&gt; on the Gentoo wiki.&lt;/p&gt;

&lt;h1 id="bin-packages-in-a-repository"&gt;Bin packages in a repository&lt;/h1&gt;

&lt;p&gt;Binary packages in &lt;code&gt;::gentoo&lt;/code&gt; (the official Gentoo repository) have the 
 &lt;u&gt;-bin&lt;/u&gt; suffix.&lt;/p&gt;

&lt;p&gt;Those packages might have USE flags but generally they are very limited in case of customizations or code optimizations because they were compiled either by a Gentoo developer or by a given package 
 &lt;u&gt;upstream&lt;/u&gt; maintainer (or their CI/CD system).&lt;/p&gt;

&lt;p&gt;Those packages land in &lt;code&gt;::gentoo&lt;/code&gt; mostly because it is too hard (or even impossible) to compile them natively by Portage. Most of the time those packages use very complicated build systems or do not play nice with network sandbox like (e.g. Scala-based projects) or use very large frameworks/libraries like (e.g. 
 &lt;u&gt;Electron&lt;/u&gt;).&lt;/p&gt;

&lt;p&gt;They can also be added to the repository because they are very 
 &lt;u&gt;desirable&lt;/u&gt; either by normal users (e.g. &lt;a href="https://packages.gentoo.org/packages/www-client/firefox-bin"&gt;www-client/firefox-bin&lt;/a&gt;) or for (from-source) package 
 &lt;u&gt;bootstrapping&lt;/u&gt; purposes (e.g. &lt;a href="https://packages.gentoo.org/packages/dev-java/openjdk-bin"&gt;dev-java/openjdk-bin&lt;/a&gt;). Such packages are sometimes generated from the regular source packages inside &lt;code&gt;::gentoo&lt;/code&gt; and later repackaged.&lt;/p&gt;</description></item></channel></rss>