In my last blog-post I described how to create a new linux_base port. This blog-post is about the other Linuxâ€“portsÂ which make up the Linuxâ€“infrastructure in the FreeBSD Ports Collection for a given Linux-release.
WhatÂ are linux-infrastructure ports?
A linux_base port containsÂ as much as possible and at the same time as little as possibleÂ to make up a usefulÂ Linux-compatibility-experience in FreeBSD. I know, this is not a descriptiveÂ explanation. And it is not on purpose. There are no fixed rules what has to beÂ inside or what not. It â€œmaturedâ€? into the current shape. A practical example is, that there is noÂ GUI-stuff in the linux_base. While you need the GUI parts like GTKÂ or QT for software like Skype and acroread, you do not need them for headless game servers. While you may need various libraries for game servers, you may not need those for Skype or acroread. As such some standard parts are in separate ports which are named linuxâ€“LINUX_DIST_SUFFIX-NAME. For GTK and the Fedora 10 release thisÂ results inÂ linux-f10-gtk2. Such generic ports which depend upon a specific Linux-release make up the Linux-infrastructureÂ in the FreeBSD Ports Collection. Those ports are referencedÂ in port-Makefiles via the USE_LINUX_APPS variable, e.g. USE_LINUX_APPS=gtk2.
If you created a new linux_base port, you needÂ most standard infrastructure ports in a version for the Linux-release used in the linux_base port, to have the Linux-application ports in the FreeBSD Ports Collection working (if you are unlucky, some ports do not play well with the Linux-release you have chosen, but this is out of the scope of this HOWTO).
Â First we need to set the LINUX_DIST_SUFFIX variable to a value suitable to the new Linux-release. This is done in the conditional which checks the OVERRIDE_LINUX_NONBASE_PORTS variable for valid values. Add an appropriate conditional, and do not forget to add the new valid value to the IGNORE line in the last else branch of the conditional.
The next step is to check the _LINUX_APPS_ALL and _LINUX_26_APPS variables. If there are some infrastructure ports which are not available for the new Linux-release, the conditional which checks the availability ofÂ a given infrastructure port for a given Linux-release needs to beÂ modified. If at a later step you notice that there are some additionalÂ infrastructure ports necessary for the new Linux-release, _LINUX_APPS_ALL and the check-logic needs to beÂ modified too (e.g. add a new variable for your Linux-release, add the content ofÂ the variable to _LINUX_APPS_ALL, and change the check to do the right thing).
After thatÂ two tedious parts need to be done.
For each infrastructure port there is a set of variables. The name_PORT variable containsÂ the location ofÂ the port in the Ports Collection. Typically you do not have to change it (if you really want to change it, do not do it, fix the naming of the infrastructure port instead), because we use a naming convention here which includes the LINUX_DIST_SUFFIX. The name_DETECT variable is an internal variable, do not change it (if you create a new infrastructure port, copy it from somewhere else and make sure the name in value of the variable matches the port name in the name of the variable). Then there are several name_suffix_FILE variables. Leave the existing ones alone, and add a new one with the correct suffix for your new Linux-release. The value of the variable needs to beÂ an important file which is installed by the infrastructure port in question. FYI: The content of the name_suffix_FILE variables are used to set the name_DETECT variables, depending on the Linux-relase the name_DETECT variables are used to check if the port is already installed. Ideally the name_suffix_FILE variable points to a library in the port. The name_DEPENDS variable lists dependencies of this infrastructure port. If the dependencies changed in your Linux-release, you need to add a conditional toÂ change theÂ dependency if LINUX_DIST_SUFFIX is set to your Linux-release.
Normally this is all what needs to beÂ done in PORTSDIR/Mk/bsd.linux-apps.mk, the rest of the fileÂ is code to checkÂ dependencies and some correctness checks.
The second tedious part is to actually create all those infrastructure ports. Normally you can copy an existing infrastructure port, rename it, adjust the PORTNAME, PORTVERSION, PORTREVISION, MASTER_SITES, PKGNAMEPREFIX, DISTFILES, CONFLICTS (also in all other Linux-release versions of this infrastructure port), LINUX_DIST_VER, RPMVERSIONÂ (if set/neccesary) and SRC_DISTFILE variables, generate the distfileÂ checksums (make makesum), and fix the plist. I suggest to script parts of this work (as of this writing FreshportsÂ counts 68 ports where the portnameÂ starts with linux-f10-).
Adding new infrastructure ports, orÂ removing infrastructure ports forÂ a given Linux-release
If your Linux-release does not come with a package for an existing infrastructure port, just do not create a corresponding name_suffix_FILE line. You still need to do the right thing regarding dependencies of ports which depend upon this non-existing infrastructure port (ifÂ your Linux-release comes with packages for them).
To add a new infrastructure port, copy an existing block, rename the variables, set them correctly, add a new variable for your Linux-release in the first _LINUX_APPS_ALL section, add the content of this variable to _LINUX_APPS_ALL, and change theÂ check-logicÂ as described above.
If you have something which installs and deinstalls correctly, feel free to provide it on [email protected] for review/testing. If you have questions during the porting, feel also free to send a mail there.