svn commit: r47981 - head/en_US.ISO8859-1/htdocs/news/status

Sat Jan 9 20:24:15 UTC 2016

Author: bjk
Date: Sat Jan  9 20:24:13 2016
New Revision: 47981
URL: https://svnweb.freebsd.org/changeset/doc/47981

Log:
  Add entry on generating port variants from Brendan Molloy

Modified:
  head/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml

Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml
==============================================================================

--- head/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml	Sat Jan  9 20:00:45 2016	(r47980)
+++ head/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml	Sat Jan  9 20:24:13 2016	(r47981)
@@ -928,4 +928,99 @@
       </task>
     </help>
   </project>
+
+  <project cat='proj'>
+    <title>Supporting Variants in the Ports Framework</title>
+
+    <contact>
+      <person>
+	<name>
+	  <given>Brendan</given>
+	  <common>Molloy</common>
+	</name>
+	<email>brendan+freebsd at bbqsrc.net</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://github.com/bbqsrc/poudriere/compare/master...feature/variants">Poudriere PoC with Variants</url>
+      <url href="https://gist.github.com/bbqsrc/e7e3a54d84706485aa3a">Ports Makefile PoC with Examples</url>
+    </links>
+
+    <body>
+      <p>I recently became involved with &os; (as in, the last 2-3
+	weeks), and found myself quickly involved with Ports development.
+	What quickly struck me was the difficulty in providing a Python
+	package that was depended upon by multiple versions of Python.  As
+	it turns out, poudriere can currently only generate one package
+	per port, meaning that a Python version-neutral (compatible with
+	2.x and 3.x) port cannot simultaneously be packaged for each
+	variant at the same time.</p>
+
+      <p>I discussed the issue with &a.koobs;, who suggested that I
+	look into implementing a "variants protocol" within the
+	Ports framework and the necessary changes to poudriere in order to
+	allow a port to generate more than one package.</p>
+
+      <p>Support for variants is strongly needed in Ports and
+	provides significant benefits.</p>
+
+      <ul>
+	<li>It would allow Python and other languages to provide
+	  packages for dependencies for multiple language versions from the
+	  same port.</li>
+
+	<li>It alleviates the need for so-called "slave
+	  ports", as a single port could now have multiple generated
+	  packages from a single port.</li>
+
+	<li>It would have a very small impact on the greater Ports
+	  ecosystem: adding only two new variables, <tt>VARIANT</tt> and
+	  <tt>VARIANTS</tt>.</li>
+
+	<li>It would provide a more consistent approach between
+	  different packaging teams for handling variations.</li>
+      </ul>
+
+      <p>For a simple example, <tt>editors/vim-lite</tt> could
+	be folded into the <tt>editors/vim</tt> port, while still
+	generating a <tt>vim</tt> and <tt>vim-lite</tt> package.
+	For Python, <tt>VARIANTS</tt> can be derived from the already
+	used <tt>USES</tt> flags and generate compatible packages.
+	<tt>py27-foobar</tt> and <tt>py34-foobar</tt> could now be
+	consistently generated by poudriere without issue.</p>
+
+      <p>Fortunately, this is not a wishful thinking piece.  I dug
+	in my heels and have implemented a proof-of-concept implementation
+	of variants in the Ports framework, including the necessary
+	modifications to poudriere in order to support it.  It was mildly
+	upsetting to find that poudriere is mostly written in Bourne shell
+	scripts, but press on I did nonetheless.</p>
+
+      <p>I started with <a
+	  href="https://github.com/bapt/ports-wip/compare/variants">the
+	  prototype made by &a.bapt;</a> as a base, and built from there.
+	The poudriere PoC aims to limit changes as much as possible to
+	merely adding support for the new variants flags, while also at
+	the request of &a.koobs; making the logging output more
+	package-centric (as opposed to port-centric) as a result of these
+	changes.</p>
+
+      <p>This is a <strong>work in progress</strong>, and I would
+	love to hear your feedback.  I've enjoyed my first few weeks
+	working on &os;, and I hope to stay here for quite some time.</p>
+    </body>
+
+    <help>
+      <task>
+	<p>Any constructive feedback on the implementation would be
+	  very welcome!</p>
+      </task>
+
+      <task>
+	<p>Hopefully the code will be of sufficient quality to be considered
+	  for formal review in the coming months.</p>
+      </task>
+    </help>
+  </project>
 </report>
