HOWTO add linux-infrastructure ports for a new linux_base port

In my last blog-post I described how to cre­ate a new linux_base port. This blog-post is about the oth­er Lin­ux-ports which make up the Lin­ux-infra­struc­ture in the FreeB­SD Ports Col­lec­tion for a giv­en Linux-release.

What are linux-infrastructure ports?

A linux_base port con­tains as much as pos­si­ble and at the same time as lit­tle as pos­si­ble to make up a use­ful Linux-compatibility-experience in FreeB­SD. I know, this is not a descrip­tive expla­na­tion. And it is not on pur­pose. There are no fixed rules what has to be inside or what not. It “matured” into the cur­rent shape. A prac­ti­cal exam­ple is, that there is no GUI-stuff in the linux_base. While you need the GUI parts like GTK or QT for soft­ware like Skype and acrore­ad, you do not need them for head­less game servers. While you may need var­i­ous libraries for game servers, you may not need those for Skype or acrore­ad. As such some stan­dard parts are in sep­a­rate ports which are named linux-LINUX_DIST_SUFFIX-NAME. For GTK and the Fedo­ra 10 release this results in linux-f10-gtk2. Such gener­ic ports which depend upon a spe­cif­ic Linux-release make up the Linux-infrastructure in the FreeB­SD Ports Col­lec­tion. Those ports are ref­er­enced in port-Makefiles via the USE_LINUX_APPS vari­able, e.g. USE_LINUX_APPS=gtk2.

If you cre­at­ed a new linux_base port, you need most stan­dard infra­struc­ture ports in a ver­sion for the Linux-release used in the linux_base port, to have the Linux-application ports in the FreeB­SD Ports Col­lec­tion work­ing (if you are unlucky, some ports do not play well with the Linux-release you have cho­sen, but this is out of the scope of this HOWTO).

Updat­ing Mk/

 First we need to set the LINUX_DIST_SUFFIX vari­able to a val­ue suit­able to the new Linux-release. This is done in the con­di­tion­al which checks the OVERRIDE_LINUX_NONBASE_PORTS vari­able for valid val­ues. Add an appro­pri­ate con­di­tion­al, and do not for­get to add the new valid val­ue to the IGNORE line in the last else branch of the con­di­tion­al.

The next step is to check the _LINUX_APPS_ALL and _LINUX_26_APPS vari­ables. If there are some infra­struc­ture ports which are not avail­able for the new Linux-release, the con­di­tion­al which checks the avail­abil­i­ty of a giv­en infra­struc­ture port for a giv­en Linux-release needs to be mod­i­fied. If at a lat­er step you notice that there are some addi­tion­al infra­struc­ture ports nec­es­sary for the new Linux-release, _LINUX_APPS_ALL and the check-logic needs to be mod­i­fied too (e.g. add a new vari­able for your Linux-release, add the con­tent of the vari­able to _LINUX_APPS_ALL, and change the check to do the right thing).

After that two tedious parts need to be done.

For each infra­struc­ture port there is a set of vari­ables. The name_PORT vari­able con­tains the loca­tion of the port in the Ports Col­lec­tion. Typ­i­cal­ly you do not have to change it (if you real­ly want to change it, do not do it, fix the nam­ing of the infra­struc­ture port instead), because we use a nam­ing con­ven­tion here which includes the LINUX_DIST_SUFFIX. The name_DETECT vari­able is an inter­nal vari­able, do not change it (if you cre­ate a new infra­struc­ture port, copy it from some­where else and make sure the name in val­ue of the vari­able match­es the port name in the name of the vari­able). Then there are sev­er­al name_suf­fix_FILE vari­ables. Leave the exist­ing ones alone, and add a new one with the cor­rect suf­fix for your new Linux-release. The val­ue of the vari­able needs to be an impor­tant file which is installed by the infra­struc­ture port in ques­tion. FYI: The con­tent of the name_suf­fix_FILE vari­ables are used to set the name_DETECT vari­ables, depend­ing on the Linux-relase the name_DETECT vari­ables are used to check if the port is already installed. Ide­al­ly the name_suf­fix_FILE vari­able points to a library in the port. The name_DEPENDS vari­able lists depen­den­cies of this infra­struc­ture port. If the depen­den­cies changed in your Linux-release, you need to add a con­di­tion­al to change the depen­den­cy if LINUX_DIST_SUFFIX is set to your Linux-release.

Nor­mal­ly this is all what needs to be done in PORTSDIR/Mk/, the rest of the file is code to check depen­den­cies and some cor­rect­ness checks.

The sec­ond tedious part is to actu­al­ly cre­ate all those infra­struc­ture ports. Nor­mal­ly you can copy an exist­ing infra­struc­ture port, rename it, adjust the PORTNAME, PORTVERSION, PORTREVISION, MASTER_SITES, PKGNAMEPREFIX, DISTFILES, CONFLICTS (also in all oth­er Linux-release ver­sions of this infra­struc­ture port), LINUX_DIST_VER, RPMVERSION (if set/neccesary) and SRC_DISTFILE vari­ables, gen­er­ate the dis­t­file check­sums (make make­sum), and fix the plist. I sug­gest to script parts of this work (as of this writ­ing Fresh­ports counts 68 ports where the port­name starts with linux-f10-).

Adding new infra­struc­ture ports, or remov­ing infra­struc­ture ports for a giv­en Linux-release

If your Linux-release does not come with a pack­age for an exist­ing infra­struc­ture port, just do not cre­ate a cor­re­spond­ing name_suf­fix_FILE line. You still need to do the right thing regard­ing depen­den­cies of ports which depend upon this non-existing infra­struc­ture port (if your Linux-release comes with pack­ages for them).

To add a new infra­struc­ture port, copy an exist­ing block, rename the vari­ables, set them cor­rect­ly, add a new vari­able for your Linux-release in the first _LINUX_APPS_ALL sec­tion, add the con­tent of this vari­able to _LINUX_APPS_ALL, and change the check-logic as described above.

Final words

If you have some­thing which installs and dein­stalls cor­rect­ly, feel free to pro­vide it on for review/testing. If you have ques­tions dur­ing the port­ing, feel also free to send a mail there.

Send to Kin­dle

Are USB mem­o­ry sticks real­ly that bad?

Last week my ZFS cache device – an USB mem­o­ry stick – showed xxxM write errors. I got this stick for free as a pro­mo, so I do not expect it to be of high qual­i­ty (or wear-leveling or sim­i­lar life-saving things). The stick sur­vived about 9 months, dur­ing which it pro­vid­ed a nice speed-up for the access to the cor­re­spond­ing ZFS stor­age pool. I replaced it by anoth­er stick which I got for free as a pro­mo. This new stick sur­vived… one long week­end. It has now 8xxM write errors and the USB sub­sys­tem is not able to speak to it any­more. 30 min­utes ago I issued an “usb­con­fig reset” to this device, which is still not fin­ished. This leads me to the ques­tion if such sticks are real­ly that bad, or if some prob­lem crept into the USB sub­sys­tem?

If this is a prob­lem with the mem­o­ry stick itself, I should be able to repro­duce such a prob­lem on a dif­fer­ent machine with a dif­fer­ent OS. I could test this with FreeB­SD 8.1, Solaris 10u9, or Win­dows XP. What I need is an auto­mat­ed test. This rules out the Win­dows XP machine for me, I do not want to spend time to search a suit­able test which is avail­able for free and allows to be run in an auto­mat­ed way. For FreeB­SD and Solaris it prob­a­bly comes down to use some disk‑I/O bench­mark (I think there are enough to chose from in the FreeB­SD Ports Col­lec­tion) and run it in a shell-loop.

Send to Kin­dle

I switched my feed read­er

Before I have read the news feeds I am inter­est­ed in via the Fire­fox plu­g­in “brief”. It did all I want­ed it to do, but I had all the data and meta­da­ta (all the feeds and read items) only in one brows­er. I was not able to have a shared state at work and at home.

Now I installed rnews on my web­serv­er. It is multi-user capa­ble, so that mul­ti­ple peo­ple can read the feeds they are inter­est­ed in, with­out the need to have mul­ti­ple instal­la­tions. I can use it from any place where I have an inter­net con­nec­tion, with­out los­ing the state.

It is in the FreeB­SD Ports Col­lec­tion as www/rnews.

Send to Kin­dle

LAME updat­ed in the FreeB­SD ports col­lec­tion

After all the big-impact com­mits (Gnome/gettext/KDE/X11/…) have set­tled now, I took the time to update audio/lame (I iden­ti­fied more than 100 ports with an (implic­it) depen­den­cy on lame, 45 of them need­ed a portre­vi­sion bump; if I forgot/overlooked some, bump the revi­sion your­self or noti­fy me please). That is the first update of my ports where miwi@ did not beat me in com­mit­ting an update since a year (he has implic­it approval to do any­thing he wants with my ports).

I can be hap­py that he is/was this fast (and that we have such a pro­duc­tive and effi­cient com­mit­ter), or I can be sad that I do not have the time any­more to be faster than I am with such things… or both. Hmmm… I think I will go the hap­py way. 😉

Send to Kin­dle