os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Add entry on generating port variants from Brendan Molloy

Browse source
This commit is contained in:
Benjamin Kaduk 2016-01-09 20:24:13 +00:00
parent 0e8c1e950c
commit bd91c221de
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=47981
1 changed files with 95 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

95
en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml
View file

@ -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@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 &quot;variants protocol&quot; 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 &quot;slave
ports&quot;, 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>