Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Fetching contributors…

Cannot retrieve contributors at this time

file 9222 lines (6625 sloc) 370.468 kb
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587 2588 2589 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622 2623 2624 2625 2626 2627 2628 2629 2630 2631 2632 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2682 2683 2684 2685 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697 2698 2699 2700 2701 2702 2703 2704 2705 2706 2707 2708 2709 2710 2711 2712 2713 2714 2715 2716 2717 2718 2719 2720 2721 2722 2723 2724 2725 2726 2727 2728 2729 2730 2731 2732 2733 2734 2735 2736 2737 2738 2739 2740 2741 2742 2743 2744 2745 2746 2747 2748 2749 2750 2751 2752 2753 2754 2755 2756 2757 2758 2759 2760 2761 2762 2763 2764 2765 2766 2767 2768 2769 2770 2771 2772 2773 2774 2775 2776 2777 2778 2779 2780 2781 2782 2783 2784 2785 2786 2787 2788 2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2811 2812 2813 2814 2815 2816 2817 2818 2819 2820 2821 2822 2823 2824 2825 2826 2827 2828 2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853 2854 2855 2856 2857 2858 2859 2860 2861 2862 2863 2864 2865 2866 2867 2868 2869 2870 2871 2872 2873 2874 2875 2876 2877 2878 2879 2880 2881 2882 2883 2884 2885 2886 2887 2888 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 2904 2905 2906 2907 2908 2909 2910 2911 2912 2913 2914 2915 2916 2917 2918 2919 2920 2921 2922 2923 2924 2925 2926 2927 2928 2929 2930 2931 2932 2933 2934 2935 2936 2937 2938 2939 2940 2941 2942 2943 2944 2945 2946 2947 2948 2949 2950 2951 2952 2953 2954 2955 2956 2957 2958 2959 2960 2961 2962 2963 2964 2965 2966 2967 2968 2969 2970 2971 2972 2973 2974 2975 2976 2977 2978 2979 2980 2981 2982 2983 2984 2985 2986 2987 2988 2989 2990 2991 2992 2993 2994 2995 2996 2997 2998 2999 3000 3001 3002 3003 3004 3005 3006 3007 3008 3009 3010 3011 3012 3013 3014 3015 3016 3017 3018 3019 3020 3021 3022 3023 3024 3025 3026 3027 3028 3029 3030 3031 3032 3033 3034 3035 3036 3037 3038 3039 3040 3041 3042 3043 3044 3045 3046 3047 3048 3049 3050 3051 3052 3053 3054 3055 3056 3057 3058 3059 3060 3061 3062 3063 3064 3065 3066 3067 3068 3069 3070 3071 3072 3073 3074 3075 3076 3077 3078 3079 3080 3081 3082 3083 3084 3085 3086 3087 3088 3089 3090 3091 3092 3093 3094 3095 3096 3097 3098 3099 3100 3101 3102 3103 3104 3105 3106 3107 3108 3109 3110 3111 3112 3113 3114 3115 3116 3117 3118 3119 3120 3121 3122 3123 3124 3125 3126 3127 3128 3129 3130 3131 3132 3133 3134 3135 3136 3137 3138 3139 3140 3141 3142 3143 3144 3145 3146 3147 3148 3149 3150 3151 3152 3153 3154 3155 3156 3157 3158 3159 3160 3161 3162 3163 3164 3165 3166 3167 3168 3169 3170 3171 3172 3173 3174 3175 3176 3177 3178 3179 3180 3181 3182 3183 3184 3185 3186 3187 3188 3189 3190 3191 3192 3193 3194 3195 3196 3197 3198 3199 3200 3201 3202 3203 3204 3205 3206 3207 3208 3209 3210 3211 3212 3213 3214 3215 3216 3217 3218 3219 3220 3221 3222 3223 3224 3225 3226 3227 3228 3229 3230 3231 3232 3233 3234 3235 3236 3237 3238 3239 3240 3241 3242 3243 3244 3245 3246 3247 3248 3249 3250 3251 3252 3253 3254 3255 3256 3257 3258 3259 3260 3261 3262 3263 3264 3265 3266 3267 3268 3269 3270 3271 3272 3273 3274 3275 3276 3277 3278 3279 3280 3281 3282 3283 3284 3285 3286 3287 3288 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3300 3301 3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312 3313 3314 3315 3316 3317 3318 3319 3320 3321 3322 3323 3324 3325 3326 3327 3328 3329 3330 3331 3332 3333 3334 3335 3336 3337 3338 3339 3340 3341 3342 3343 3344 3345 3346 3347 3348 3349 3350 3351 3352 3353 3354 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364 3365 3366 3367 3368 3369 3370 3371 3372 3373 3374 3375 3376 3377 3378 3379 3380 3381 3382 3383 3384 3385 3386 3387 3388 3389 3390 3391 3392 3393 3394 3395 3396 3397 3398 3399 3400 3401 3402 3403 3404 3405 3406 3407 3408 3409 3410 3411 3412 3413 3414 3415 3416 3417 3418 3419 3420 3421 3422 3423 3424 3425 3426 3427 3428 3429 3430 3431 3432 3433 3434 3435 3436 3437 3438 3439 3440 3441 3442 3443 3444 3445 3446 3447 3448 3449 3450 3451 3452 3453 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466 3467 3468 3469 3470 3471 3472 3473 3474 3475 3476 3477 3478 3479 3480 3481 3482 3483 3484 3485 3486 3487 3488 3489 3490 3491 3492 3493 3494 3495 3496 3497 3498 3499 3500 3501 3502 3503 3504 3505 3506 3507 3508 3509 3510 3511 3512 3513 3514 3515 3516 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530 3531 3532 3533 3534 3535 3536 3537 3538 3539 3540 3541 3542 3543 3544 3545 3546 3547 3548 3549 3550 3551 3552 3553 3554 3555 3556 3557 3558 3559 3560 3561 3562 3563 3564 3565 3566 3567 3568 3569 3570 3571 3572 3573 3574 3575 3576 3577 3578 3579 3580 3581 3582 3583 3584 3585 3586 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597 3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3608 3609 3610 3611 3612 3613 3614 3615 3616 3617 3618 3619 3620 3621 3622 3623 3624 3625 3626 3627 3628 3629 3630 3631 3632 3633 3634 3635 3636 3637 3638 3639 3640 3641 3642 3643 3644 3645 3646 3647 3648 3649 3650 3651 3652 3653 3654 3655 3656 3657 3658 3659 3660 3661 3662 3663 3664 3665 3666 3667 3668 3669 3670 3671 3672 3673 3674 3675 3676 3677 3678 3679 3680 3681 3682 3683 3684 3685 3686 3687 3688 3689 3690 3691 3692 3693 3694 3695 3696 3697 3698 3699 3700 3701 3702 3703 3704 3705 3706 3707 3708 3709 3710 3711 3712 3713 3714 3715 3716 3717 3718 3719 3720 3721 3722 3723 3724 3725 3726 3727 3728 3729 3730 3731 3732 3733 3734 3735 3736 3737 3738 3739 3740 3741 3742 3743 3744 3745 3746 3747 3748 3749 3750 3751 3752 3753 3754 3755 3756 3757 3758 3759 3760 3761 3762 3763 3764 3765 3766 3767 3768 3769 3770 3771 3772 3773 3774 3775 3776 3777 3778 3779 3780 3781 3782 3783 3784 3785 3786 3787 3788 3789 3790 3791 3792 3793 3794 3795 3796 3797 3798 3799 3800 3801 3802 3803 3804 3805 3806 3807 3808 3809 3810 3811 3812 3813 3814 3815 3816 3817 3818 3819 3820 3821 3822 3823 3824 3825 3826 3827 3828 3829 3830 3831 3832 3833 3834 3835 3836 3837 3838 3839 3840 3841 3842 3843 3844 3845 3846 3847 3848 3849 3850 3851 3852 3853 3854 3855 3856 3857 3858 3859 3860 3861 3862 3863 3864 3865 3866 3867 3868 3869 3870 3871 3872 3873 3874 3875 3876 3877 3878 3879 3880 3881 3882 3883 3884 3885 3886 3887 3888 3889 3890 3891 3892 3893 3894 3895 3896 3897 3898 3899 3900 3901 3902 3903 3904 3905 3906 3907 3908 3909 3910 3911 3912 3913 3914 3915 3916 3917 3918 3919 3920 3921 3922 3923 3924 3925 3926 3927 3928 3929 3930 3931 3932 3933 3934 3935 3936 3937 3938 3939 3940 3941 3942 3943 3944 3945 3946 3947 3948 3949 3950 3951 3952 3953 3954 3955 3956 3957 3958 3959 3960 3961 3962 3963 3964 3965 3966 3967 3968 3969 3970 3971 3972 3973 3974 3975 3976 3977 3978 3979 3980 3981 3982 3983 3984 3985 3986 3987 3988 3989 3990 3991 3992 3993 3994 3995 3996 3997 3998 3999 4000 4001 4002 4003 4004 4005 4006 4007 4008 4009 4010 4011 4012 4013 4014 4015 4016 4017 4018 4019 4020 4021 4022 4023 4024 4025 4026 4027 4028 4029 4030 4031 4032 4033 4034 4035 4036 4037 4038 4039 4040 4041 4042 4043 4044 4045 4046 4047 4048 4049 4050 4051 4052 4053 4054 4055 4056 4057 4058 4059 4060 4061 4062 4063 4064 4065 4066 4067 4068 4069 4070 4071 4072 4073 4074 4075 4076 4077 4078 4079 4080 4081 4082 4083 4084 4085 4086 4087 4088 4089 4090 4091 4092 4093 4094 4095 4096 4097 4098 4099 4100 4101 4102 4103 4104 4105 4106 4107 4108 4109 4110 4111 4112 4113 4114 4115 4116 4117 4118 4119 4120 4121 4122 4123 4124 4125 4126 4127 4128 4129 4130 4131 4132 4133 4134 4135 4136 4137 4138 4139 4140 4141 4142 4143 4144 4145 4146 4147 4148 4149 4150 4151 4152 4153 4154 4155 4156 4157 4158 4159 4160 4161 4162 4163 4164 4165 4166 4167 4168 4169 4170 4171 4172 4173 4174 4175 4176 4177 4178 4179 4180 4181 4182 4183 4184 4185 4186 4187 4188 4189 4190 4191 4192 4193 4194 4195 4196 4197 4198 4199 4200 4201 4202 4203 4204 4205 4206 4207 4208 4209 4210 4211 4212 4213 4214 4215 4216 4217 4218 4219 4220 4221 4222 4223 4224 4225 4226 4227 4228 4229 4230 4231 4232 4233 4234 4235 4236 4237 4238 4239 4240 4241 4242 4243 4244 4245 4246 4247 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258 4259 4260 4261 4262 4263 4264 4265 4266 4267 4268 4269 4270 4271 4272 4273 4274 4275 4276 4277 4278 4279 4280 4281 4282 4283 4284 4285 4286 4287 4288 4289 4290 4291 4292 4293 4294 4295 4296 4297 4298 4299 4300 4301 4302 4303 4304 4305 4306 4307 4308 4309 4310 4311 4312 4313 4314 4315 4316 4317 4318 4319 4320 4321 4322 4323 4324 4325 4326 4327 4328 4329 4330 4331 4332 4333 4334 4335 4336 4337 4338 4339 4340 4341 4342 4343 4344 4345 4346 4347 4348 4349 4350 4351 4352 4353 4354 4355 4356 4357 4358 4359 4360 4361 4362 4363 4364 4365 4366 4367 4368 4369 4370 4371 4372 4373 4374 4375 4376 4377 4378 4379 4380 4381 4382 4383 4384 4385 4386 4387 4388 4389 4390 4391 4392 4393 4394 4395 4396 4397 4398 4399 4400 4401 4402 4403 4404 4405 4406 4407 4408 4409 4410 4411 4412 4413 4414 4415 4416 4417 4418 4419 4420 4421 4422 4423 4424 4425 4426 4427 4428 4429 4430 4431 4432 4433 4434 4435 4436 4437 4438 4439 4440 4441 4442 4443 4444 4445 4446 4447 4448 4449 4450 4451 4452 4453 4454 4455 4456 4457 4458 4459 4460 4461 4462 4463 4464 4465 4466 4467 4468 4469 4470 4471 4472 4473 4474 4475 4476 4477 4478 4479 4480 4481 4482 4483 4484 4485 4486 4487 4488 4489 4490 4491 4492 4493 4494 4495 4496 4497 4498 4499 4500 4501 4502 4503 4504 4505 4506 4507 4508 4509 4510 4511 4512 4513 4514 4515 4516 4517 4518 4519 4520 4521 4522 4523 4524 4525 4526 4527 4528 4529 4530 4531 4532 4533 4534 4535 4536 4537 4538 4539 4540 4541 4542 4543 4544 4545 4546 4547 4548 4549 4550 4551 4552 4553 4554 4555 4556 4557 4558 4559 4560 4561 4562 4563 4564 4565 4566 4567 4568 4569 4570 4571 4572 4573 4574 4575 4576 4577 4578 4579 4580 4581 4582 4583 4584 4585 4586 4587 4588 4589 4590 4591 4592 4593 4594 4595 4596 4597 4598 4599 4600 4601 4602 4603 4604 4605 4606 4607 4608 4609 4610 4611 4612 4613 4614 4615 4616 4617 4618 4619 4620 4621 4622 4623 4624 4625 4626 4627 4628 4629 4630 4631 4632 4633 4634 4635 4636 4637 4638 4639 4640 4641 4642 4643 4644 4645 4646 4647 4648 4649 4650 4651 4652 4653 4654 4655 4656 4657 4658 4659 4660 4661 4662 4663 4664 4665 4666 4667 4668 4669 4670 4671 4672 4673 4674 4675 4676 4677 4678 4679 4680 4681 4682 4683 4684 4685 4686 4687 4688 4689 4690 4691 4692 4693 4694 4695 4696 4697 4698 4699 4700 4701 4702 4703 4704 4705 4706 4707 4708 4709 4710 4711 4712 4713 4714 4715 4716 4717 4718 4719 4720 4721 4722 4723 4724 4725 4726 4727 4728 4729 4730 4731 4732 4733 4734 4735 4736 4737 4738 4739 4740 4741 4742 4743 4744 4745 4746 4747 4748 4749 4750 4751 4752 4753 4754 4755 4756 4757 4758 4759 4760 4761 4762 4763 4764 4765 4766 4767 4768 4769 4770 4771 4772 4773 4774 4775 4776 4777 4778 4779 4780 4781 4782 4783 4784 4785 4786 4787 4788 4789 4790 4791 4792 4793 4794 4795 4796 4797 4798 4799 4800 4801 4802 4803 4804 4805 4806 4807 4808 4809 4810 4811 4812 4813 4814 4815 4816 4817 4818 4819 4820 4821 4822 4823 4824 4825 4826 4827 4828 4829 4830 4831 4832 4833 4834 4835 4836 4837 4838 4839 4840 4841 4842 4843 4844 4845 4846 4847 4848 4849 4850 4851 4852 4853 4854 4855 4856 4857 4858 4859 4860 4861 4862 4863 4864 4865 4866 4867 4868 4869 4870 4871 4872 4873 4874 4875 4876 4877 4878 4879 4880 4881 4882 4883 4884 4885 4886 4887 4888 4889 4890 4891 4892 4893 4894 4895 4896 4897 4898 4899 4900 4901 4902 4903 4904 4905 4906 4907 4908 4909 4910 4911 4912 4913 4914 4915 4916 4917 4918 4919 4920 4921 4922 4923 4924 4925 4926 4927 4928 4929 4930 4931 4932 4933 4934 4935 4936 4937 4938 4939 4940 4941 4942 4943 4944 4945 4946 4947 4948 4949 4950 4951 4952 4953 4954 4955 4956 4957 4958 4959 4960 4961 4962 4963 4964 4965 4966 4967 4968 4969 4970 4971 4972 4973 4974 4975 4976 4977 4978 4979 4980 4981 4982 4983 4984 4985 4986 4987 4988 4989 4990 4991 4992 4993 4994 4995 4996 4997 4998 4999 5000 5001 5002 5003 5004 5005 5006 5007 5008 5009 5010 5011 5012 5013 5014 5015 5016 5017 5018 5019 5020 5021 5022 5023 5024 5025 5026 5027 5028 5029 5030 5031 5032 5033 5034 5035 5036 5037 5038 5039 5040 5041 5042 5043 5044 5045 5046 5047 5048 5049 5050 5051 5052 5053 5054 5055 5056 5057 5058 5059 5060 5061 5062 5063 5064 5065 5066 5067 5068 5069 5070 5071 5072 5073 5074 5075 5076 5077 5078 5079 5080 5081 5082 5083 5084 5085 5086 5087 5088 5089 5090 5091 5092 5093 5094 5095 5096 5097 5098 5099 5100 5101 5102 5103 5104 5105 5106 5107 5108 5109 5110 5111 5112 5113 5114 5115 5116 5117 5118 5119 5120 5121 5122 5123 5124 5125 5126 5127 5128 5129 5130 5131 5132 5133 5134 5135 5136 5137 5138 5139 5140 5141 5142 5143 5144 5145 5146 5147 5148 5149 5150 5151 5152 5153 5154 5155 5156 5157 5158 5159 5160 5161 5162 5163 5164 5165 5166 5167 5168 5169 5170 5171 5172 5173 5174 5175 5176 5177 5178 5179 5180 5181 5182 5183 5184 5185 5186 5187 5188 5189 5190 5191 5192 5193 5194 5195 5196 5197 5198 5199 5200 5201 5202 5203 5204 5205 5206 5207 5208 5209 5210 5211 5212 5213 5214 5215 5216 5217 5218 5219 5220 5221 5222 5223 5224 5225 5226 5227 5228 5229 5230 5231 5232 5233 5234 5235 5236 5237 5238 5239 5240 5241 5242 5243 5244 5245 5246 5247 5248 5249 5250 5251 5252 5253 5254 5255 5256 5257 5258 5259 5260 5261 5262 5263 5264 5265 5266 5267 5268 5269 5270 5271 5272 5273 5274 5275 5276 5277 5278 5279 5280 5281 5282 5283 5284 5285 5286 5287 5288 5289 5290 5291 5292 5293 5294 5295 5296 5297 5298 5299 5300 5301 5302 5303 5304 5305 5306 5307 5308 5309 5310 5311 5312 5313 5314 5315 5316 5317 5318 5319 5320 5321 5322 5323 5324 5325 5326 5327 5328 5329 5330 5331 5332 5333 5334 5335 5336 5337 5338 5339 5340 5341 5342 5343 5344 5345 5346 5347 5348 5349 5350 5351 5352 5353 5354 5355 5356 5357 5358 5359 5360 5361 5362 5363 5364 5365 5366 5367 5368 5369 5370 5371 5372 5373 5374 5375 5376 5377 5378 5379 5380 5381 5382 5383 5384 5385 5386 5387 5388 5389 5390 5391 5392 5393 5394 5395 5396 5397 5398 5399 5400 5401 5402 5403 5404 5405 5406 5407 5408 5409 5410 5411 5412 5413 5414 5415 5416 5417 5418 5419 5420 5421 5422 5423 5424 5425 5426 5427 5428 5429 5430 5431 5432 5433 5434 5435 5436 5437 5438 5439 5440 5441 5442 5443 5444 5445 5446 5447 5448 5449 5450 5451 5452 5453 5454 5455 5456 5457 5458 5459 5460 5461 5462 5463 5464 5465 5466 5467 5468 5469 5470 5471 5472 5473 5474 5475 5476 5477 5478 5479 5480 5481 5482 5483 5484 5485 5486 5487 5488 5489 5490 5491 5492 5493 5494 5495 5496 5497 5498 5499 5500 5501 5502 5503 5504 5505 5506 5507 5508 5509 5510 5511 5512 5513 5514 5515 5516 5517 5518 5519 5520 5521 5522 5523 5524 5525 5526 5527 5528 5529 5530 5531 5532 5533 5534 5535 5536 5537 5538 5539 5540 5541 5542 5543 5544 5545 5546 5547 5548 5549 5550 5551 5552 5553 5554 5555 5556 5557 5558 5559 5560 5561 5562 5563 5564 5565 5566 5567 5568 5569 5570 5571 5572 5573 5574 5575 5576 5577 5578 5579 5580 5581 5582 5583 5584 5585 5586 5587 5588 5589 5590 5591 5592 5593 5594 5595 5596 5597 5598 5599 5600 5601 5602 5603 5604 5605 5606 5607 5608 5609 5610 5611 5612 5613 5614 5615 5616 5617 5618 5619 5620 5621 5622 5623 5624 5625 5626 5627 5628 5629 5630 5631 5632 5633 5634 5635 5636 5637 5638 5639 5640 5641 5642 5643 5644 5645 5646 5647 5648 5649 5650 5651 5652 5653 5654 5655 5656 5657 5658 5659 5660 5661 5662 5663 5664 5665 5666 5667 5668 5669 5670 5671 5672 5673 5674 5675 5676 5677 5678 5679 5680 5681 5682 5683 5684 5685 5686 5687 5688 5689 5690 5691 5692 5693 5694 5695 5696 5697 5698 5699 5700 5701 5702 5703 5704 5705 5706 5707 5708 5709 5710 5711 5712 5713 5714 5715 5716 5717 5718 5719 5720 5721 5722 5723 5724 5725 5726 5727 5728 5729 5730 5731 5732 5733 5734 5735 5736 5737 5738 5739 5740 5741 5742 5743 5744 5745 5746 5747 5748 5749 5750 5751 5752 5753 5754 5755 5756 5757 5758 5759 5760 5761 5762 5763 5764 5765 5766 5767 5768 5769 5770 5771 5772 5773 5774 5775 5776 5777 5778 5779 5780 5781 5782 5783 5784 5785 5786 5787 5788 5789 5790 5791 5792 5793 5794 5795 5796 5797 5798 5799 5800 5801 5802 5803 5804 5805 5806 5807 5808 5809 5810 5811 5812 5813 5814 5815 5816 5817 5818 5819 5820 5821 5822 5823 5824 5825 5826 5827 5828 5829 5830 5831 5832 5833 5834 5835 5836 5837 5838 5839 5840 5841 5842 5843 5844 5845 5846 5847 5848 5849 5850 5851 5852 5853 5854 5855 5856 5857 5858 5859 5860 5861 5862 5863 5864 5865 5866 5867 5868 5869 5870 5871 5872 5873 5874 5875 5876 5877 5878 5879 5880 5881 5882 5883 5884 5885 5886 5887 5888 5889 5890 5891 5892 5893 5894 5895 5896 5897 5898 5899 5900 5901 5902 5903 5904 5905 5906 5907 5908 5909 5910 5911 5912 5913 5914 5915 5916 5917 5918 5919 5920 5921 5922 5923 5924 5925 5926 5927 5928 5929 5930 5931 5932 5933 5934 5935 5936 5937 5938 5939 5940 5941 5942 5943 5944 5945 5946 5947 5948 5949 5950 5951 5952 5953 5954 5955 5956 5957 5958 5959 5960 5961 5962 5963 5964 5965 5966 5967 5968 5969 5970 5971 5972 5973 5974 5975 5976 5977 5978 5979 5980 5981 5982 5983 5984 5985 5986 5987 5988 5989 5990 5991 5992 5993 5994 5995 5996 5997 5998 5999 6000 6001 6002 6003 6004 6005 6006 6007 6008 6009 6010 6011 6012 6013 6014 6015 6016 6017 6018 6019 6020 6021 6022 6023 6024 6025 6026 6027 6028 6029 6030 6031 6032 6033 6034 6035 6036 6037 6038 6039 6040 6041 6042 6043 6044 6045 6046 6047 6048 6049 6050 6051 6052 6053 6054 6055 6056 6057 6058 6059 6060 6061 6062 6063 6064 6065 6066 6067 6068 6069 6070 6071 6072 6073 6074 6075 6076 6077 6078 6079 6080 6081 6082 6083 6084 6085 6086 6087 6088 6089 6090 6091 6092 6093 6094 6095 6096 6097 6098 6099 6100 6101 6102 6103 6104 6105 6106 6107 6108 6109 6110 6111 6112 6113 6114 6115 6116 6117 6118 6119 6120 6121 6122 6123 6124 6125 6126 6127 6128 6129 6130 6131 6132 6133 6134 6135 6136 6137 6138 6139 6140 6141 6142 6143 6144 6145 6146 6147 6148 6149 6150 6151 6152 6153 6154 6155 6156 6157 6158 6159 6160 6161 6162 6163 6164 6165 6166 6167 6168 6169 6170 6171 6172 6173 6174 6175 6176 6177 6178 6179 6180 6181 6182 6183 6184 6185 6186 6187 6188 6189 6190 6191 6192 6193 6194 6195 6196 6197 6198 6199 6200 6201 6202 6203 6204 6205 6206 6207 6208 6209 6210 6211 6212 6213 6214 6215 6216 6217 6218 6219 6220 6221 6222 6223 6224 6225 6226 6227 6228 6229 6230 6231 6232 6233 6234 6235 6236 6237 6238 6239 6240 6241 6242 6243 6244 6245 6246 6247 6248 6249 6250 6251 6252 6253 6254 6255 6256 6257 6258 6259 6260 6261 6262 6263 6264 6265 6266 6267 6268 6269 6270 6271 6272 6273 6274 6275 6276 6277 6278 6279 6280 6281 6282 6283 6284 6285 6286 6287 6288 6289 6290 6291 6292 6293 6294 6295 6296 6297 6298 6299 6300 6301 6302 6303 6304 6305 6306 6307 6308 6309 6310 6311 6312 6313 6314 6315 6316 6317 6318 6319 6320 6321 6322 6323 6324 6325 6326 6327 6328 6329 6330 6331 6332 6333 6334 6335 6336 6337 6338 6339 6340 6341 6342 6343 6344 6345 6346 6347 6348 6349 6350 6351 6352 6353 6354 6355 6356 6357 6358 6359 6360 6361 6362 6363 6364 6365 6366 6367 6368 6369 6370 6371 6372 6373 6374 6375 6376 6377 6378 6379 6380 6381 6382 6383 6384 6385 6386 6387 6388 6389 6390 6391 6392 6393 6394 6395 6396 6397 6398 6399 6400 6401 6402 6403 6404 6405 6406 6407 6408 6409 6410 6411 6412 6413 6414 6415 6416 6417 6418 6419 6420 6421 6422 6423 6424 6425 6426 6427 6428 6429 6430 6431 6432 6433 6434 6435 6436 6437 6438 6439 6440 6441 6442 6443 6444 6445 6446 6447 6448 6449 6450 6451 6452 6453 6454 6455 6456 6457 6458 6459 6460 6461 6462 6463 6464 6465 6466 6467 6468 6469 6470 6471 6472 6473 6474 6475 6476 6477 6478 6479 6480 6481 6482 6483 6484 6485 6486 6487 6488 6489 6490 6491 6492 6493 6494 6495 6496 6497 6498 6499 6500 6501 6502 6503 6504 6505 6506 6507 6508 6509 6510 6511 6512 6513 6514 6515 6516 6517 6518 6519 6520 6521 6522 6523 6524 6525 6526 6527 6528 6529 6530 6531 6532 6533 6534 6535 6536 6537 6538 6539 6540 6541 6542 6543 6544 6545 6546 6547 6548 6549 6550 6551 6552 6553 6554 6555 6556 6557 6558 6559 6560 6561 6562 6563 6564 6565 6566 6567 6568 6569 6570 6571 6572 6573 6574 6575 6576 6577 6578 6579 6580 6581 6582 6583 6584 6585 6586 6587 6588 6589 6590 6591 6592 6593 6594 6595 6596 6597 6598 6599 6600 6601 6602 6603 6604 6605 6606 6607 6608 6609 6610 6611 6612 6613 6614 6615 6616 6617 6618 6619 6620 6621 6622 6623 6624 6625 6626 6627 6628 6629 6630 6631 6632 6633 6634 6635 6636 6637 6638 6639 6640 6641 6642 6643 6644 6645 6646 6647 6648 6649 6650 6651 6652 6653 6654 6655 6656 6657 6658 6659 6660 6661 6662 6663 6664 6665 6666 6667 6668 6669 6670 6671 6672 6673 6674 6675 6676 6677 6678 6679 6680 6681 6682 6683 6684 6685 6686 6687 6688 6689 6690 6691 6692 6693 6694 6695 6696 6697 6698 6699 6700 6701 6702 6703 6704 6705 6706 6707 6708 6709 6710 6711 6712 6713 6714 6715 6716 6717 6718 6719 6720 6721 6722 6723 6724 6725 6726 6727 6728 6729 6730 6731 6732 6733 6734 6735 6736 6737 6738 6739 6740 6741 6742 6743 6744 6745 6746 6747 6748 6749 6750 6751 6752 6753 6754 6755 6756 6757 6758 6759 6760 6761 6762 6763 6764 6765 6766 6767 6768 6769 6770 6771 6772 6773 6774 6775 6776 6777 6778 6779 6780 6781 6782 6783 6784 6785 6786 6787 6788 6789 6790 6791 6792 6793 6794 6795 6796 6797 6798 6799 6800 6801 6802 6803 6804 6805 6806 6807 6808 6809 6810 6811 6812 6813 6814 6815 6816 6817 6818 6819 6820 6821 6822 6823 6824 6825 6826 6827 6828 6829 6830 6831 6832 6833 6834 6835 6836 6837 6838 6839 6840 6841 6842 6843 6844 6845 6846 6847 6848 6849 6850 6851 6852 6853 6854 6855 6856 6857 6858 6859 6860 6861 6862 6863 6864 6865 6866 6867 6868 6869 6870 6871 6872 6873 6874 6875 6876 6877 6878 6879 6880 6881 6882 6883 6884 6885 6886 6887 6888 6889 6890 6891 6892 6893 6894 6895 6896 6897 6898 6899 6900 6901 6902 6903 6904 6905 6906 6907 6908 6909 6910 6911 6912 6913 6914 6915 6916 6917 6918 6919 6920 6921 6922 6923 6924 6925 6926 6927 6928 6929 6930 6931 6932 6933 6934 6935 6936 6937 6938 6939 6940 6941 6942 6943 6944 6945 6946 6947 6948 6949 6950 6951 6952 6953 6954 6955 6956 6957 6958 6959 6960 6961 6962 6963 6964 6965 6966 6967 6968 6969 6970 6971 6972 6973 6974 6975 6976 6977 6978 6979 6980 6981 6982 6983 6984 6985 6986 6987 6988 6989 6990 6991 6992 6993 6994 6995 6996 6997 6998 6999 7000 7001 7002 7003 7004 7005 7006 7007 7008 7009 7010 7011 7012 7013 7014 7015 7016 7017 7018 7019 7020 7021 7022 7023 7024 7025 7026 7027 7028 7029 7030 7031 7032 7033 7034 7035 7036 7037 7038 7039 7040 7041 7042 7043 7044 7045 7046 7047 7048 7049 7050 7051 7052 7053 7054 7055 7056 7057 7058 7059 7060 7061 7062 7063 7064 7065 7066 7067 7068 7069 7070 7071 7072 7073 7074 7075 7076 7077 7078 7079 7080 7081 7082 7083 7084 7085 7086 7087 7088 7089 7090 7091 7092 7093 7094 7095 7096 7097 7098 7099 7100 7101 7102 7103 7104 7105 7106 7107 7108 7109 7110 7111 7112 7113 7114 7115 7116 7117 7118 7119 7120 7121 7122 7123 7124 7125 7126 7127 7128 7129 7130 7131 7132 7133 7134 7135 7136 7137 7138 7139 7140 7141 7142 7143 7144 7145 7146 7147 7148 7149 7150 7151 7152 7153 7154 7155 7156 7157 7158 7159 7160 7161 7162 7163 7164 7165 7166 7167 7168 7169 7170 7171 7172 7173 7174 7175 7176 7177 7178 7179 7180 7181 7182 7183 7184 7185 7186 7187 7188 7189 7190 7191 7192 7193 7194 7195 7196 7197 7198 7199 7200 7201 7202 7203 7204 7205 7206 7207 7208 7209 7210 7211 7212 7213 7214 7215 7216 7217 7218 7219 7220 7221 7222 7223 7224 7225 7226 7227 7228 7229 7230 7231 7232 7233 7234 7235 7236 7237 7238 7239 7240 7241 7242 7243 7244 7245 7246 7247 7248 7249 7250 7251 7252 7253 7254 7255 7256 7257 7258 7259 7260 7261 7262 7263 7264 7265 7266 7267 7268 7269 7270 7271 7272 7273 7274 7275 7276 7277 7278 7279 7280 7281 7282 7283 7284 7285 7286 7287 7288 7289 7290 7291 7292 7293 7294 7295 7296 7297 7298 7299 7300 7301 7302 7303 7304 7305 7306 7307 7308 7309 7310 7311 7312 7313 7314 7315 7316 7317 7318 7319 7320 7321 7322 7323 7324 7325 7326 7327 7328 7329 7330 7331 7332 7333 7334 7335 7336 7337 7338 7339 7340 7341 7342 7343 7344 7345 7346 7347 7348 7349 7350 7351 7352 7353 7354 7355 7356 7357 7358 7359 7360 7361 7362 7363 7364 7365 7366 7367 7368 7369 7370 7371 7372 7373 7374 7375 7376 7377 7378 7379 7380 7381 7382 7383 7384 7385 7386 7387 7388 7389 7390 7391 7392 7393 7394 7395 7396 7397 7398 7399 7400 7401 7402 7403 7404 7405 7406 7407 7408 7409 7410 7411 7412 7413 7414 7415 7416 7417 7418 7419 7420 7421 7422 7423 7424 7425 7426 7427 7428 7429 7430 7431 7432 7433 7434 7435 7436 7437 7438 7439 7440 7441 7442 7443 7444 7445 7446 7447 7448 7449 7450 7451 7452 7453 7454 7455 7456 7457 7458 7459 7460 7461 7462 7463 7464 7465 7466 7467 7468 7469 7470 7471 7472 7473 7474 7475 7476 7477 7478 7479 7480 7481 7482 7483 7484 7485 7486 7487 7488 7489 7490 7491 7492 7493 7494 7495 7496 7497 7498 7499 7500 7501 7502 7503 7504 7505 7506 7507 7508 7509 7510 7511 7512 7513 7514 7515 7516 7517 7518 7519 7520 7521 7522 7523 7524 7525 7526 7527 7528 7529 7530 7531 7532 7533 7534 7535 7536 7537 7538 7539 7540 7541 7542 7543 7544 7545 7546 7547 7548 7549 7550 7551 7552 7553 7554 7555 7556 7557 7558 7559 7560 7561 7562 7563 7564 7565 7566 7567 7568 7569 7570 7571 7572 7573 7574 7575 7576 7577 7578 7579 7580 7581 7582 7583 7584 7585 7586 7587 7588 7589 7590 7591 7592 7593 7594 7595 7596 7597 7598 7599 7600 7601 7602 7603 7604 7605 7606 7607 7608 7609 7610 7611 7612 7613 7614 7615 7616 7617 7618 7619 7620 7621 7622 7623 7624 7625 7626 7627 7628 7629 7630 7631 7632 7633 7634 7635 7636 7637 7638 7639 7640 7641 7642 7643 7644 7645 7646 7647 7648 7649 7650 7651 7652 7653 7654 7655 7656 7657 7658 7659 7660 7661 7662 7663 7664 7665 7666 7667 7668 7669 7670 7671 7672 7673 7674 7675 7676 7677 7678 7679 7680 7681 7682 7683 7684 7685 7686 7687 7688 7689 7690 7691 7692 7693 7694 7695 7696 7697 7698 7699 7700 7701 7702 7703 7704 7705 7706 7707 7708 7709 7710 7711 7712 7713 7714 7715 7716 7717 7718 7719 7720 7721 7722 7723 7724 7725 7726 7727 7728 7729 7730 7731 7732 7733 7734 7735 7736 7737 7738 7739 7740 7741 7742 7743 7744 7745 7746 7747 7748 7749 7750 7751 7752 7753 7754 7755 7756 7757 7758 7759 7760 7761 7762 7763 7764 7765 7766 7767 7768 7769 7770 7771 7772 7773 7774 7775 7776 7777 7778 7779 7780 7781 7782 7783 7784 7785 7786 7787 7788 7789 7790 7791 7792 7793 7794 7795 7796 7797 7798 7799 7800 7801 7802 7803 7804 7805 7806 7807 7808 7809 7810 7811 7812 7813 7814 7815 7816 7817 7818 7819 7820 7821 7822 7823 7824 7825 7826 7827 7828 7829 7830 7831 7832 7833 7834 7835 7836 7837 7838 7839 7840 7841 7842 7843 7844 7845 7846 7847 7848 7849 7850 7851 7852 7853 7854 7855 7856 7857 7858 7859 7860 7861 7862 7863 7864 7865 7866 7867 7868 7869 7870 7871 7872 7873 7874 7875 7876 7877 7878 7879 7880 7881 7882 7883 7884 7885 7886 7887 7888 7889 7890 7891 7892 7893 7894 7895 7896 7897 7898 7899 7900 7901 7902 7903 7904 7905 7906 7907 7908 7909 7910 7911 7912 7913 7914 7915 7916 7917 7918 7919 7920 7921 7922 7923 7924 7925 7926 7927 7928 7929 7930 7931 7932 7933 7934 7935 7936 7937 7938 7939 7940 7941 7942 7943 7944 7945 7946 7947 7948 7949 7950 7951 7952 7953 7954 7955 7956 7957 7958 7959 7960 7961 7962 7963 7964 7965 7966 7967 7968 7969 7970 7971 7972 7973 7974 7975 7976 7977 7978 7979 7980 7981 7982 7983 7984 7985 7986 7987 7988 7989 7990 7991 7992 7993 7994 7995 7996 7997 7998 7999 8000 8001 8002 8003 8004 8005 8006 8007 8008 8009 8010 8011 8012 8013 8014 8015 8016 8017 8018 8019 8020 8021 8022 8023 8024 8025 8026 8027 8028 8029 8030 8031 8032 8033 8034 8035 8036 8037 8038 8039 8040 8041 8042 8043 8044 8045 8046 8047 8048 8049 8050 8051 8052 8053 8054 8055 8056 8057 8058 8059 8060 8061 8062 8063 8064 8065 8066 8067 8068 8069 8070 8071 8072 8073 8074 8075 8076 8077 8078 8079 8080 8081 8082 8083 8084 8085 8086 8087 8088 8089 8090 8091 8092 8093 8094 8095 8096 8097 8098 8099 8100 8101 8102 8103 8104 8105 8106 8107 8108 8109 8110 8111 8112 8113 8114 8115 8116 8117 8118 8119 8120 8121 8122 8123 8124 8125 8126 8127 8128 8129 8130 8131 8132 8133 8134 8135 8136 8137 8138 8139 8140 8141 8142 8143 8144 8145 8146 8147 8148 8149 8150 8151 8152 8153 8154 8155 8156 8157 8158 8159 8160 8161 8162 8163 8164 8165 8166 8167 8168 8169 8170 8171 8172 8173 8174 8175 8176 8177 8178 8179 8180 8181 8182 8183 8184 8185 8186 8187 8188 8189 8190 8191 8192 8193 8194 8195 8196 8197 8198 8199 8200 8201 8202 8203 8204 8205 8206 8207 8208 8209 8210 8211 8212 8213 8214 8215 8216 8217 8218 8219 8220 8221 8222 8223 8224 8225 8226 8227 8228 8229 8230 8231 8232 8233 8234 8235 8236 8237 8238 8239 8240 8241 8242 8243 8244 8245 8246 8247 8248 8249 8250 8251 8252 8253 8254 8255 8256 8257 8258 8259 8260 8261 8262 8263 8264 8265 8266 8267 8268 8269 8270 8271 8272 8273 8274 8275 8276 8277 8278 8279 8280 8281 8282 8283 8284 8285 8286 8287 8288 8289 8290 8291 8292 8293 8294 8295 8296 8297 8298 8299 8300 8301 8302 8303 8304 8305 8306 8307 8308 8309 8310 8311 8312 8313 8314 8315 8316 8317 8318 8319 8320 8321 8322 8323 8324 8325 8326 8327 8328 8329 8330 8331 8332 8333 8334 8335 8336 8337 8338 8339 8340 8341 8342 8343 8344 8345 8346 8347 8348 8349 8350 8351 8352 8353 8354 8355 8356 8357 8358 8359 8360 8361 8362 8363 8364 8365 8366 8367 8368 8369 8370 8371 8372 8373 8374 8375 8376 8377 8378 8379 8380 8381 8382 8383 8384 8385 8386 8387 8388 8389 8390 8391 8392 8393 8394 8395 8396 8397 8398 8399 8400 8401 8402 8403 8404 8405 8406 8407 8408 8409 8410 8411 8412 8413 8414 8415 8416 8417 8418 8419 8420 8421 8422 8423 8424 8425 8426 8427 8428 8429 8430 8431 8432 8433 8434 8435 8436 8437 8438 8439 8440 8441 8442 8443 8444 8445 8446 8447 8448 8449 8450 8451 8452 8453 8454 8455 8456 8457 8458 8459 8460 8461 8462 8463 8464 8465 8466 8467 8468 8469 8470 8471 8472 8473 8474 8475 8476 8477 8478 8479 8480 8481 8482 8483 8484 8485 8486 8487 8488 8489 8490 8491 8492 8493 8494 8495 8496 8497 8498 8499 8500 8501 8502 8503 8504 8505 8506 8507 8508 8509 8510 8511 8512 8513 8514 8515 8516 8517 8518 8519 8520 8521 8522 8523 8524 8525 8526 8527 8528 8529 8530 8531 8532 8533 8534 8535 8536 8537 8538 8539 8540 8541 8542 8543 8544 8545 8546 8547 8548 8549 8550 8551 8552 8553 8554 8555 8556 8557 8558 8559 8560 8561 8562 8563 8564 8565 8566 8567 8568 8569 8570 8571 8572 8573 8574 8575 8576 8577 8578 8579 8580 8581 8582 8583 8584 8585 8586 8587 8588 8589 8590 8591 8592 8593 8594 8595 8596 8597 8598 8599 8600 8601 8602 8603 8604 8605 8606 8607 8608 8609 8610 8611 8612 8613 8614 8615 8616 8617 8618 8619 8620 8621 8622 8623 8624 8625 8626 8627 8628 8629 8630 8631 8632 8633 8634 8635 8636 8637 8638 8639 8640 8641 8642 8643 8644 8645 8646 8647 8648 8649 8650 8651 8652 8653 8654 8655 8656 8657 8658 8659 8660 8661 8662 8663 8664 8665 8666 8667 8668 8669 8670 8671 8672 8673 8674 8675 8676 8677 8678 8679 8680 8681 8682 8683 8684 8685 8686 8687 8688 8689 8690 8691 8692 8693 8694 8695 8696 8697 8698 8699 8700 8701 8702 8703 8704 8705 8706 8707 8708 8709 8710 8711 8712 8713 8714 8715 8716 8717 8718 8719 8720 8721 8722 8723 8724 8725 8726 8727 8728 8729 8730 8731 8732 8733 8734 8735 8736 8737 8738 8739 8740 8741 8742 8743 8744 8745 8746 8747 8748 8749 8750 8751 8752 8753 8754 8755 8756 8757 8758 8759 8760 8761 8762 8763 8764 8765 8766 8767 8768 8769 8770 8771 8772 8773 8774 8775 8776 8777 8778 8779 8780 8781 8782 8783 8784 8785 8786 8787 8788 8789 8790 8791 8792 8793 8794 8795 8796 8797 8798 8799 8800 8801 8802 8803 8804 8805 8806 8807 8808 8809 8810 8811 8812 8813 8814 8815 8816 8817 8818 8819 8820 8821 8822 8823 8824 8825 8826 8827 8828 8829 8830 8831 8832 8833 8834 8835 8836 8837 8838 8839 8840 8841 8842 8843 8844 8845 8846 8847 8848 8849 8850 8851 8852 8853 8854 8855 8856 8857 8858 8859 8860 8861 8862 8863 8864 8865 8866 8867 8868 8869 8870 8871 8872 8873 8874 8875 8876 8877 8878 8879 8880 8881 8882 8883 8884 8885 8886 8887 8888 8889 8890 8891 8892 8893 8894 8895 8896 8897 8898 8899 8900 8901 8902 8903 8904 8905 8906 8907 8908 8909 8910 8911 8912 8913 8914 8915 8916 8917 8918 8919 8920 8921 8922 8923 8924 8925 8926 8927 8928 8929 8930 8931 8932 8933 8934 8935 8936 8937 8938 8939 8940 8941 8942 8943 8944 8945 8946 8947 8948 8949 8950 8951 8952 8953 8954 8955 8956 8957 8958 8959 8960 8961 8962 8963 8964 8965 8966 8967 8968 8969 8970 8971 8972 8973 8974 8975 8976 8977 8978 8979 8980 8981 8982 8983 8984 8985 8986 8987 8988 8989 8990 8991 8992 8993 8994 8995 8996 8997 8998 8999 9000 9001 9002 9003 9004 9005 9006 9007 9008 9009 9010 9011 9012 9013 9014 9015 9016 9017 9018 9019 9020 9021 9022 9023 9024 9025 9026 9027 9028 9029 9030 9031 9032 9033 9034 9035 9036 9037 9038 9039 9040 9041 9042 9043 9044 9045 9046 9047 9048 9049 9050 9051 9052 9053 9054 9055 9056 9057 9058 9059 9060 9061 9062 9063 9064 9065 9066 9067 9068 9069 9070 9071 9072 9073 9074 9075 9076 9077 9078 9079 9080 9081 9082 9083 9084 9085 9086 9087 9088 9089 9090 9091 9092 9093 9094 9095 9096 9097 9098 9099 9100 9101 9102 9103 9104 9105 9106 9107 9108 9109 9110 9111 9112 9113 9114 9115 9116 9117 9118 9119 9120 9121 9122 9123 9124 9125 9126 9127 9128 9129 9130 9131 9132 9133 9134 9135 9136 9137 9138 9139 9140 9141 9142 9143 9144 9145 9146 9147 9148 9149 9150 9151 9152 9153 9154 9155 9156 9157 9158 9159 9160 9161 9162 9163 9164 9165 9166 9167 9168 9169 9170 9171 9172 9173 9174 9175 9176 9177 9178 9179 9180 9181 9182 9183 9184 9185 9186 9187 9188 9189 9190 9191 9192 9193 9194 9195 9196 9197 9198 9199 9200 9201 9202 9203 9204 9205 9206 9207 9208 9209 9210 9211 9212 9213 9214 9215 9216 9217 9218 9219 9220 9221 9222
The pkgsrc guide

Documentation on the NetBSD packages system

Alistair Crooks

<agc@NetBSD.org>

Hubert Feyrer

<hubertf@NetBSD.org>

The pkgsrc Developers

Copyright 1994-2007 The NetBSD Foundation, Inc

$NetBSD: pkgsrc.xml,v 1.26 2007/09/18 08:17:21 rillig Exp $

Abstract

pkgsrc is a centralized package management system for Unix-like operating
systems. This guide provides information for users and developers of pkgsrc. It
covers installation of binary and source packages, creation of binary and
source packages and a high-level overview about the infrastructure.

-------------------------------------------------------------------------------

Table of Contents

1. What is pkgsrc?

    1.1. Introduction

        1.1.1. Why pkgsrc?
        1.1.2. Supported platforms

    1.2. Overview
    1.3. Terminology

        1.3.1. Roles involved in pkgsrc

    1.4. Typography

I. The pkgsrc user's guide

    2. Where to get pkgsrc and how to keep it up-to-date

        2.1. Getting pkgsrc for the first time

            2.1.1. As tar file
            2.1.2. Via anonymous CVS

        2.2. Keeping pkgsrc up-to-date

            2.2.1. Via tar files
            2.2.2. Via CVS

    3. Using pkgsrc on systems other than NetBSD

        3.1. Binary distribution
        3.2. Bootstrapping pkgsrc
        3.3. Platform-specific notes

            3.3.1. Darwin (Mac OS X)
            3.3.2. FreeBSD
            3.3.3. Interix
            3.3.4. IRIX
            3.3.5. Linux
            3.3.6. OpenBSD
            3.3.7. Solaris

    4. Using pkgsrc

        4.1. Using binary packages

            4.1.1. Finding binary packages
            4.1.2. Installing binary packages
            4.1.3. Deinstalling packages
            4.1.4. Getting information about installed packages
            4.1.5. Checking for security vulnerabilities in installed packages
            4.1.6. Finding if newer versions of your installed packages are in
                pkgsrc
            4.1.7. Other administrative functions
            4.1.8. A word of warning

        4.2. Building packages from source

            4.2.1. Requirements
            4.2.2. Fetching distfiles
            4.2.3. How to build and install

    5. Configuring pkgsrc

        5.1. General configuration
        5.2. Variables affecting the build process
        5.3. Variables affecting the installation process
        5.4. Selecting and configuring the compiler

            5.4.1. Selecting the compiler
            5.4.2. Additional flags to the compiler (CFLAGS)
            5.4.3. Additional flags to the linker (LDFLAGS)

        5.5. Developer/advanced settings
        5.6. Selecting Build Options

    6. Creating binary packages

        6.1. Building a single binary package
        6.2. Settings for creation of binary packages

    7. Creating binary packages for everything in pkgsrc (bulk builds)

        7.1. Think first, build later
        7.2. Requirements of a bulk build
        7.3. Running an old-style bulk build

            7.3.1. Configuration
            7.3.2. Other environmental considerations
            7.3.3. Operation
            7.3.4. What it does
            7.3.5. Disk space requirements
            7.3.6. Setting up a sandbox for chrooted builds
            7.3.7. Building a partial set of packages
            7.3.8. Uploading results of a bulk build

        7.4. Running a pbulk-style bulk build

            7.4.1. Preparation
            7.4.2. Configuration

        7.5. Creating a multiple CD-ROM packages collection

            7.5.1. Example of cdpack

    8. Directory layout of the installed files

        8.1. File system layout in ${LOCALBASE}
        8.2. File system layout in ${VARBASE}

    9. Frequently Asked Questions

        9.1. Are there any mailing lists for pkg-related discussion?
        9.2. Where's the pkgviews documentation?
        9.3. Utilities for package management (pkgtools)
        9.4. How to use pkgsrc as non-root
        9.5. How to resume transfers when fetching distfiles?
        9.6. How can I install/use modular X.org from pkgsrc?
        9.7. How to fetch files from behind a firewall
        9.8. How do I tell make fetch to do passive FTP?
        9.9. How to fetch all distfiles at once
        9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc"
            mean?
        9.11. What does "Could not find bsd.own.mk" mean?
        9.12. Using 'sudo' with pkgsrc
        9.13. How do I change the location of configuration files?
        9.14. Automated security checks
        9.15. Why do some packages ignore my CFLAGS?
        9.16. A package does not build. What shall I do?
        9.17. What does "Makefile appears to contain unresolved cvs/rcs/???
            merge conflicts" mean?

II. The pkgsrc developer's guide

    10. Creating a new pkgsrc package from scratch

        10.1. Common types of packages

            10.1.1. Perl modules
            10.1.2. KDE applications
            10.1.3. Python modules and programs

        10.2. Examples

            10.2.1. How the www/nvu package came into pkgsrc

    11. Package components - files, directories and contents

        11.1. Makefile
        11.2. distinfo
        11.3. patches/*

            11.3.1. Structure of a single patch file
            11.3.2. Creating patch files
            11.3.3. Sources where the patch files come from
            11.3.4. Patching guidelines
            11.3.5. Feedback to the author

        11.4. Other mandatory files
        11.5. Optional files

            11.5.1. Files affecting the binary package
            11.5.2. Files affecting the build process
            11.5.3. Files affecting nothing at all

        11.6. work*
        11.7. files/*

    12. Programming in Makefiles

        12.1. Caveats
        12.2. Makefile variables

            12.2.1. Naming conventions

        12.3. Code snippets

            12.3.1. Adding things to a list
            12.3.2. Converting an internal list into an external list
            12.3.3. Passing variables to a shell command
            12.3.4. Quoting guideline
            12.3.5. Workaround for a bug in BSD Make

    13. PLIST issues

        13.1. RCS ID
        13.2. Semi-automatic PLIST generation
        13.3. Tweaking output of make print-PLIST
        13.4. Variable substitution in PLIST
        13.5. Man page compression
        13.6. Changing PLIST source with PLIST_SRC
        13.7. Platform-specific and differing PLISTs
        13.8. Sharing directories between packages

    14. Buildlink methodology

        14.1. Converting packages to use buildlink3
        14.2. Writing buildlink3.mk files

            14.2.1. Anatomy of a buildlink3.mk file
            14.2.2. Updating BUILDLINK_API_DEPENDS.pkg and
                BUILDLINK_ABI_DEPENDS.pkg in buildlink3.mk files

        14.3. Writing builtin.mk files

            14.3.1. Anatomy of a builtin.mk file
            14.3.2. Global preferences for native or pkgsrc software

    15. The pkginstall framework

        15.1. Files and directories outside the installation prefix

            15.1.1. Directory manipulation
            15.1.2. File manipulation

        15.2. Configuration files

            15.2.1. How PKG_SYSCONFDIR is set
            15.2.2. Telling the software where configuration files are
            15.2.3. Patching installations
            15.2.4. Disabling handling of configuration files

        15.3. System startup scripts

            15.3.1. Disabling handling of system startup scripts

        15.4. System users and groups
        15.5. System shells

            15.5.1. Disabling shell registration

        15.6. Fonts

            15.6.1. Disabling automatic update of the fonts databases

    16. Options handling

        16.1. Global default options
        16.2. Converting packages to use bsd.options.mk
        16.3. Option Names
        16.4. Determining the options of dependencies

    17. The build process

        17.1. Introduction
        17.2. Program location
        17.3. Directories used during the build process
        17.4. Running a phase
        17.5. The fetch phase

            17.5.1. What to fetch and where to get it from
            17.5.2. How are the files fetched?

        17.6. The checksum phase
        17.7. The extract phase
        17.8. The patch phase
        17.9. The tools phase
        17.10. The wrapper phase
        17.11. The configure phase
        17.12. The build phase
        17.13. The test phase
        17.14. The install phase
        17.15. The package phase
        17.16. Cleaning up
        17.17. Other helpful targets

    18. Tools needed for building or running

        18.1. Tools for pkgsrc builds
        18.2. Tools needed by packages
        18.3. Tools provided by platforms
        18.4. Questions regarding the tools

    19. Making your package work

        19.1. General operation

            19.1.1. Portability of packages
            19.1.2. How to pull in user-settable variables from mk.conf
            19.1.3. User interaction
            19.1.4. Handling licenses
            19.1.5. Restricted packages
            19.1.6. Handling dependencies
            19.1.7. Handling conflicts with other packages
            19.1.8. Packages that cannot or should not be built
            19.1.9. Packages which should not be deleted, once installed
            19.1.10. Handling packages with security problems
            19.1.11. How to handle incrementing versions when fixing an
                existing package
            19.1.12. Substituting variable text in the package files (the SUBST
                framework)

        19.2. Fixing problems in the fetch phase

            19.2.1. Packages whose distfiles aren't available for plain
                downloading
            19.2.2. How to handle modified distfiles with the 'old' name

        19.3. Fixing problems in the configure phase

            19.3.1. Shared libraries - libtool
            19.3.2. Using libtool on GNU packages that already support libtool
            19.3.3. GNU Autoconf/Automake

        19.4. Programming languages

            19.4.1. C, C++, and Fortran
            19.4.2. Java
            19.4.3. Packages containing perl scripts
            19.4.4. Other programming languages

        19.5. Fixing problems in the build phase

            19.5.1. Compiling C and C++ code conditionally
            19.5.2. How to handle compiler bugs
            19.5.3. Undefined reference to "..."
            19.5.4. Running out of memory

        19.6. Fixing problems in the install phase

            19.6.1. Creating needed directories
            19.6.2. Where to install documentation
            19.6.3. Installing highscore files
            19.6.4. Adding DESTDIR support to packages
            19.6.5. Packages with hardcoded paths to other interpreters
            19.6.6. Packages installing perl modules
            19.6.7. Packages installing info files
            19.6.8. Packages installing man pages
            19.6.9. Packages installing GConf data files
            19.6.10. Packages installing scrollkeeper/rarian data files
            19.6.11. Packages installing X11 fonts
            19.6.12. Packages installing GTK2 modules
            19.6.13. Packages installing SGML or XML data
            19.6.14. Packages installing extensions to the MIME database
            19.6.15. Packages using intltool
            19.6.16. Packages installing startup scripts
            19.6.17. Packages installing TeX modules
            19.6.18. Packages supporting running binaries in emulation
            19.6.19. Packages installing hicolor theme icons
            19.6.20. Packages installing desktop files

        19.7. Marking packages as having problems

    20. Debugging
    21. Submitting and Committing

        21.1. Submitting binary packages
        21.2. Submitting source packages (for non-NetBSD-developers)
        21.3. General notes when adding, updating, or removing packages
        21.4. Committing: Adding a package to CVS
        21.5. Updating a package to a newer version
        21.6. Renaming a package in pkgsrc
        21.7. Moving a package in pkgsrc

    22. Frequently Asked Questions
    23. GNOME packaging and porting

        23.1. Meta packages
        23.2. Packaging a GNOME application
        23.3. Updating GNOME to a newer version
        23.4. Patching guidelines

III. The pkgsrc infrastructure internals

    24. Design of the pkgsrc infrastructure

        24.1. The meaning of variable definitions
        24.2. Avoiding problems before they arise
        24.3. Variable evaluation

            24.3.1. At load time
            24.3.2. At runtime

        24.4. How can variables be specified?
        24.5. Designing interfaces for Makefile fragments

            24.5.1. Procedures with parameters
            24.5.2. Actions taken on behalf of parameters

        24.6. The order in which files are loaded

            24.6.1. The order in bsd.prefs.mk
            24.6.2. The order in bsd.pkg.mk

    25. Regression tests

        25.1. The regression tests framework
        25.2. Running the regression tests
        25.3. Adding a new regression test

            25.3.1. Overridable functions
            25.3.2. Helper functions

    26. Porting pkgsrc

        26.1. Porting pkgsrc to a new operating system
        26.2. Adding support for a new compiler

A. A simple example package: bison

    A.1. files

        A.1.1. Makefile
        A.1.2. DESCR
        A.1.3. PLIST
        A.1.4. Checking a package with pkglint

    A.2. Steps for building, installing, packaging

B. Build logs

    B.1. Building figlet
    B.2. Packaging figlet

C. Directory layout of the pkgsrc FTP server

    C.1. distfiles: The distributed source files
    C.2. misc: Miscellaneous things
    C.3. packages: Binary packages
    C.4. reports: Bulk build reports
    C.5. current, pkgsrc-20xxQy: source packages

D. Editing guidelines for the pkgsrc guide

    D.1. Make targets
    D.2. Procedure

List of Tables

1.1. Platforms supported by pkgsrc
11.1. Patching examples
23.1. PLIST handling for GNOME packages

Chapter 1. What is pkgsrc?

Table of Contents

1.1. Introduction

    1.1.1. Why pkgsrc?
    1.1.2. Supported platforms

1.2. Overview
1.3. Terminology

    1.3.1. Roles involved in pkgsrc

1.4. Typography

1.1. Introduction

There is a lot of software freely available for Unix-based systems, which is
usually available in form of the source code. Before such software can be used,
it needs to be configured to the local system, compiled and installed, and this
is exactly what The NetBSD Packages Collection (pkgsrc) does. pkgsrc also has
some basic commands to handle binary packages, so that not every user has to
build the packages for himself, which is a time-costly task.

pkgsrc currently contains several thousand packages, including:

  * www/apache - The Apache web server

  * www/firefox - The Firefox web browser

  * meta-pkgs/gnome - The GNOME Desktop Environment

  * meta-pkgs/kde3 - The K Desktop Environment

...just to name a few.

pkgsrc has built-in support for handling varying dependencies, such as pthreads
and X11, and extended features such as IPv6 support on a range of platforms.

1.1.1. Why pkgsrc?

pkgsrc provides the following key features:

  * Easy building of software from source as well as the creation and
    installation of binary packages. The source and latest patches are
    retrieved from a master or mirror download site, checksum verified, then
    built on your system. Support for binary-only distributions is available
    for both native platforms and NetBSD emulated platforms.

  * All packages are installed in a consistent directory tree, including
    binaries, libraries, man pages and other documentation.

  * Package dependencies, including when performing package updates, are
    handled automatically. The configuration files of various packages are
    handled automatically during updates, so local changes are preserved.

  * Like NetBSD, pkgsrc is designed with portability in mind and consists of
    highly portable code. This allows the greatest speed of development when
    porting to a new platform. This portability also ensures that pkgsrc is
    consistent across all platforms.

  * The installation prefix, acceptable software licenses, international
    encryption requirements and build-time options for a large number of
    packages are all set in a simple, central configuration file.

  * The entire source (not including the distribution files) is freely
    available under a BSD license, so you may extend and adapt pkgsrc to your
    needs. Support for local packages and patches is available right out of the
    box, so you can configure it specifically for your environment.

The following principles are basic to pkgsrc:

  * "It should only work if it's right." ? That means, if a package contains
    bugs, it's better to find them and to complain about them rather than to
    just install the package and hope that it works. There are numerous checks
    in pkgsrc that try to find such bugs: Static analysis tools (pkgtools/
    pkglint), build-time checks (portability of shell scripts), and
    post-installation checks (installed files, references to shared libraries,
    script interpreters).

  * "If it works, it should work everywhere" ? Like NetBSD has been ported to
    many hardware architectures, pkgsrc has been ported to many operating
    systems. Care is taken that packages behave the same on all platforms.

1.1.2. Supported platforms

pkgsrc consists of both a source distribution and a binary distribution for
these operating systems. After retrieving the required source or binaries, you
can be up and running with pkgsrc in just minutes!

pkgsrc was derived from FreeBSD's ports system, and initially developed for
NetBSD only. Since then, pkgsrc has grown a lot, and now supports the following
platforms:

Table 1.1. Platforms supported by pkgsrc

+----------------------------------------------------------------+
| Platform |Date Support Added|
|---------------------------------------------+------------------|
|NetBSD | Aug 1997 |
|---------------------------------------------+------------------|
|Solaris | Mar 1999 |
|---------------------------------------------+------------------|
|Linux | Jun 1999 |
|---------------------------------------------+------------------|
|Darwin (Mac OS X) | Oct 2001 |
|---------------------------------------------+------------------|
|FreeBSD | Nov 2002 |
|---------------------------------------------+------------------|
|OpenBSD | Nov 2002 |
|---------------------------------------------+------------------|
|IRIX | Dec 2002 |
|---------------------------------------------+------------------|
|BSD/OS | Dec 2003 |
|---------------------------------------------+------------------|
|AIX | Dec 2003 |
|---------------------------------------------+------------------|
|Interix (Microsoft Windows Services for Unix)| Mar 2004 |
|---------------------------------------------+------------------|
|DragonFlyBSD | Oct 2004 |
|---------------------------------------------+------------------|
|OSF/1 | Nov 2004 |
|---------------------------------------------+------------------|
|HP-UX | Apr 2007 |
|---------------------------------------------+------------------|
|Haiku | Sep 2010 |
+----------------------------------------------------------------+


1.2. Overview

This document is divided into three parts. The first, The pkgsrc user's guide,
describes how one can use one of the packages in the Package Collection, either
by installing a precompiled binary package, or by building one's own copy using
the NetBSD package system. The second part, The pkgsrc developer's guide,
explains how to prepare a package so it can be easily built by other NetBSD
users without knowing about the package's building details. The third part, The
pkgsrc infrastructure internals is intended for those who want to understand
how pkgsrc is implemented.

This document is available in various formats: HTML, PDF, PS, TXT.

1.3. Terminology

There has been a lot of talk about "ports", "packages", etc. so far. Here is a
description of all the terminology used within this document.

Package

    A set of files and building instructions that describe what's necessary to
    build a certain piece of software using pkgsrc. Packages are traditionally
    stored under /usr/pkgsrc.

The NetBSD package system

    This is the former name of "pkgsrc". It is part of the NetBSD operating
    system and can be bootstrapped to run on non-NetBSD operating systems as
    well. It handles building (compiling), installing, and removing of
    packages.

Distfile

    This term describes the file or files that are provided by the author of
    the piece of software to distribute his work. All the changes necessary to
    build on NetBSD are reflected in the corresponding package. Usually the
    distfile is in the form of a compressed tar-archive, but other types are
    possible, too. Distfiles are usually stored below /usr/pkgsrc/distfiles.

Port

    This is the term used by FreeBSD and OpenBSD people for what we call a
    package. In NetBSD terminology, "port" refers to a different architecture.

Precompiled/binary package

    A set of binaries built with pkgsrc from a distfile and stuffed together in
    a single .tgz file so it can be installed on machines of the same machine
    architecture without the need to recompile. Packages are usually generated
    in /usr/pkgsrc/packages; there is also an archive on ftp.NetBSD.org.

    Sometimes, this is referred to by the term "package" too, especially in the
    context of precompiled packages.

Program

    The piece of software to be installed which will be constructed from all
    the files in the distfile by the actions defined in the corresponding
    package.

1.3.1. Roles involved in pkgsrc

pkgsrc users

    The pkgsrc users are people who use the packages provided by pkgsrc.
    Typically they are system administrators. The people using the software
    that is inside the packages (maybe called "end users") are not covered by
    the pkgsrc guide.

    There are two kinds of pkgsrc users: Some only want to install pre-built
    binary packages. Others build the pkgsrc packages from source, either for
    installing them directly or for building binary packages themselves. For
    pkgsrc users Part I, "The pkgsrc user's guide" should provide all necessary
    documentation.

package maintainers

    A package maintainer creates packages as described in Part II, "The pkgsrc
    developer's guide".

infrastructure developers

    These people are involved in all those files that live in the mk/ directory
    and below. Only these people should need to read through Part III, "The
    pkgsrc infrastructure internals", though others might be curious, too.

1.4. Typography

When giving examples for commands, shell prompts are used to show if the
command should/can be issued as root, or if "normal" user privileges are
sufficient. We use a # for root's shell prompt, and a % for users' shell
prompt, assuming they use the C-shell or tcsh.

Part I. The pkgsrc user's guide

Table of Contents

2. Where to get pkgsrc and how to keep it up-to-date

    2.1. Getting pkgsrc for the first time

        2.1.1. As tar file
        2.1.2. Via anonymous CVS

    2.2. Keeping pkgsrc up-to-date

        2.2.1. Via tar files
        2.2.2. Via CVS

3. Using pkgsrc on systems other than NetBSD

    3.1. Binary distribution
    3.2. Bootstrapping pkgsrc
    3.3. Platform-specific notes

        3.3.1. Darwin (Mac OS X)
        3.3.2. FreeBSD
        3.3.3. Interix
        3.3.4. IRIX
        3.3.5. Linux
        3.3.6. OpenBSD
        3.3.7. Solaris

4. Using pkgsrc

    4.1. Using binary packages

        4.1.1. Finding binary packages
        4.1.2. Installing binary packages
        4.1.3. Deinstalling packages
        4.1.4. Getting information about installed packages
        4.1.5. Checking for security vulnerabilities in installed packages
        4.1.6. Finding if newer versions of your installed packages are in
            pkgsrc
        4.1.7. Other administrative functions
        4.1.8. A word of warning

    4.2. Building packages from source

        4.2.1. Requirements
        4.2.2. Fetching distfiles
        4.2.3. How to build and install

5. Configuring pkgsrc

    5.1. General configuration
    5.2. Variables affecting the build process
    5.3. Variables affecting the installation process
    5.4. Selecting and configuring the compiler

        5.4.1. Selecting the compiler
        5.4.2. Additional flags to the compiler (CFLAGS)
        5.4.3. Additional flags to the linker (LDFLAGS)

    5.5. Developer/advanced settings
    5.6. Selecting Build Options

6. Creating binary packages

    6.1. Building a single binary package
    6.2. Settings for creation of binary packages

7. Creating binary packages for everything in pkgsrc (bulk builds)

    7.1. Think first, build later
    7.2. Requirements of a bulk build
    7.3. Running an old-style bulk build

        7.3.1. Configuration
        7.3.2. Other environmental considerations
        7.3.3. Operation
        7.3.4. What it does
        7.3.5. Disk space requirements
        7.3.6. Setting up a sandbox for chrooted builds
        7.3.7. Building a partial set of packages
        7.3.8. Uploading results of a bulk build

    7.4. Running a pbulk-style bulk build

        7.4.1. Preparation
        7.4.2. Configuration

    7.5. Creating a multiple CD-ROM packages collection

        7.5.1. Example of cdpack

8. Directory layout of the installed files

    8.1. File system layout in ${LOCALBASE}
    8.2. File system layout in ${VARBASE}

9. Frequently Asked Questions

    9.1. Are there any mailing lists for pkg-related discussion?
    9.2. Where's the pkgviews documentation?
    9.3. Utilities for package management (pkgtools)
    9.4. How to use pkgsrc as non-root
    9.5. How to resume transfers when fetching distfiles?
    9.6. How can I install/use modular X.org from pkgsrc?
    9.7. How to fetch files from behind a firewall
    9.8. How do I tell make fetch to do passive FTP?
    9.9. How to fetch all distfiles at once
    9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
    9.11. What does "Could not find bsd.own.mk" mean?
    9.12. Using 'sudo' with pkgsrc
    9.13. How do I change the location of configuration files?
    9.14. Automated security checks
    9.15. Why do some packages ignore my CFLAGS?
    9.16. A package does not build. What shall I do?
    9.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
        conflicts" mean?

Chapter 2. Where to get pkgsrc and how to keep it up-to-date

Table of Contents

2.1. Getting pkgsrc for the first time

    2.1.1. As tar file
    2.1.2. Via anonymous CVS

2.2. Keeping pkgsrc up-to-date

    2.2.1. Via tar files
    2.2.2. Via CVS

Before you download and extract the files, you need to decide where you want to
extract them. When using pkgsrc as root user, pkgsrc is usually installed in /
usr/pkgsrc. You are though free to install the sources and binary packages
wherever you want in your filesystem, provided that the pathname does not
contain white-space or other characters that are interpreted specially by the
shell and some other programs. A safe bet is to use only letters, digits,
underscores and dashes.

2.1. Getting pkgsrc for the first time

Before you download any pkgsrc files, you should decide whether you want the
current branch or the stable branch. The latter is forked on a quarterly basis
from the current branch and only gets modified for security updates. The names
of the stable branches are built from the year and the quarter, for example
2009Q1.

The second step is to decide how you want to download pkgsrc. You can get it as
a tar file or via CVS. Both ways are described here.

2.1.1. As tar file

The primary download location for all pkgsrc files is ftp://ftp.NetBSD.org/pub/
pkgsrc/. There are a number of subdirectories for different purposes, which are
described in detail in Appendix C, Directory layout of the pkgsrc FTP server.

The tar file for the current branch is in the directory current and is called
pkgsrc.tar.gz. It is autogenerated daily.

The tar file for the stable branch 2009Q1 is in the directory pkgsrc-2009Q1 and
is also called pkgsrc-2009Q1.tar.gz.

To download a pkgsrc stable tarball, run:

$ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/pkgsrc-20xxQy/pkgsrc-20xxQy.tar.gz

Where pkgsrc-20xxQy is the stable branch to be downloaded, for example, "
pkgsrc-2009Q1".

Then, extract it with:

$ tar -xzf pkgsrc-20xxQy.tar.gz -C /usr

This will create the directory pkgsrc/ in /usr/ and all the package source will
be stored under /usr/pkgsrc/.

To download pkgsrc-current, run:

$ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz

2.1.2. Via anonymous CVS

To fetch a specific pkgsrc stable branch, run:

$ cd /usr && cvs -q -z2 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -r pkgsrc-20xxQy -P pkgsrc

Where pkgsrc-20xxQy is the stable branch to be checked out, for example, "
pkgsrc-2009Q1"

This will create the directory pkgsrc/ in your /usr/ directory and all the
package source will be stored under /usr/pkgsrc/.

To fetch the pkgsrc current branch, run:

$ cd /usr && cvs -q -z2 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc

Refer to the list of available mirrors to choose a faster CVS mirror, if
needed.

If you get error messages from rsh, you need to set CVS_RSH variable. E.g.:

$ cd /usr && env CVS_RSH=ssh cvs -q -z2 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc

Refer to documentation on your command shell how to set CVS_RSH=ssh
permanently. For Bourne shells, you can set it in your .profile or better
globally in /etc/profile:

# set CVS remote shell command
CVS_RSH=ssh
export CVS_RSH

By default, CVS doesn't do things like most people would expect it to do. But
there is a way to convince CVS, by creating a file called .cvsrc in your home
directory and saving the following lines to it. This file will save you lots of
headache and some bug reports, so we strongly recommend it. You can find an
explanation of this file in the CVS documentation.

# recommended CVS configuration file from the pkgsrc guide
cvs -q -z2
checkout -P
update -dP
diff -upN
rdiff -u
release -d

2.2. Keeping pkgsrc up-to-date

The preferred way to keep pkgsrc up-to-date is via CVS (which also works if you
have first installed it via a tar file). It saves bandwidth and hard disk
activity, compared to downloading the tar file again.

2.2.1. Via tar files

Warning

When updating from a tar file, you first need to completely remove the old
pkgsrc directory. Otherwise those files that have been removed from pkgsrc in
the mean time will not be removed on your local disk, resulting in
inconsistencies. When removing the old files, any changes that you have done to
the pkgsrc files will be lost after updating. Therefore updating via CVS is
strongly recommended.

Note that by default the distfiles and the binary packages are saved in the
pkgsrc tree, so don't forget to rescue them before updating. You can also
configure pkgsrc to use other than the default directories by setting the
DISTDIR and PACKAGES variables. See Chapter 5, Configuring pkgsrc for the
details.

To update pkgsrc from a tar file, download the tar file as explained above.
Then, make sure that you have not made any changes to the files in the pkgsrc
directory. Remove the pkgsrc directory and extract the new tar file. Done.

2.2.2. Via CVS

To update pkgsrc via CVS, change to the pkgsrc directory and run cvs:

$ cd /usr/pkgsrc && cvs update -dP

If you get error messages from rsh, you need to set CVS_RSH variable as
described above. E.g.:

$ cd /usr/pkgsrc && env CVS_RSH=ssh cvs up -dP

2.2.2.1. Switching between different pkgsrc branches

When updating pkgsrc, the CVS program keeps track of the branch you selected.
But if you, for whatever reason, want to switch from the stable branch to the
current one, you can do it by adding the option "-A" after the "update"
keyword. To switch from the current branch back to the stable branch, add the "
-rpkgsrc-2009Q3" option.

2.2.2.2. What happens to my changes when updating?

When you update pkgsrc, the CVS program will only touch those files that are
registered in the CVS repository. That means that any packages that you created
on your own will stay unmodified. If you change files that are managed by CVS,
later updates will try to merge your changes with those that have been done by
others. See the CVS manual, chapter "update" for details.

Chapter 3. Using pkgsrc on systems other than NetBSD

Table of Contents

3.1. Binary distribution
3.2. Bootstrapping pkgsrc
3.3. Platform-specific notes

    3.3.1. Darwin (Mac OS X)
    3.3.2. FreeBSD
    3.3.3. Interix
    3.3.4. IRIX
    3.3.5. Linux
    3.3.6. OpenBSD
    3.3.7. Solaris

3.1. Binary distribution

See Section 4.1, "Using binary packages".

3.2. Bootstrapping pkgsrc

Installing the bootstrap kit from source should be as simple as:

# env CVS_RSH=ssh cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout pkgsrc
# cd pkgsrc/bootstrap
# ./bootstrap


See Chapter 2, Where to get pkgsrc and how to keep it up-to-date for other ways
to get pkgsrc before bootstrapping. The given bootstrap command will use the
defaults of /usr/pkg for the prefix where programs will be installed in, and /
var/db/pkg for the package database directory where pkgsrc will do its internal
bookkeeping. However, these can also be set using command-line arguments.

Note

The bootstrap installs a bmake tool. Use this bmake when building via pkgsrc.
For examples in this guide, use bmake instead of "make".

3.3. Platform-specific notes

Here are some platform-specific notes you should be aware of.

3.3.1. Darwin (Mac OS X)

Darwin 5.x and up are supported. Before you start, you will need to download
and install the Mac OS X Developer Tools from Apple's Developer Connection. See
http://developer.apple.com/macosx/ for details. Also, make sure you install X11
(an optional package included with the Developer Tools) if you intend to build
packages that use the X11 Window System.

3.3.2. FreeBSD

FreeBSD 8.3 and 9.0 have been tested and are supported, other versions may
work.

Care should be taken so that the tools that this kit installs do not conflict
with the FreeBSD userland tools. There are several steps:

 1. FreeBSD stores its ports pkg database in /var/db/pkg. It is therefore
    recommended that you choose a different location (e.g. /usr/pkgdb) by using
    the --pkgdbdir option to the bootstrap script.

 2. If you do not intend to use the FreeBSD ports tools, it's probably a good
    idea to move them out of the way to avoid confusion, e.g.

    # cd /usr/sbin
    # mv pkg_add pkg_add.orig
    # mv pkg_create pkg_create.orig
    # mv pkg_delete pkg_delete.orig
    # mv pkg_info pkg_info.orig


 3. An example mk.conf file will be placed in /etc/mk.conf.example file when
    you use the bootstrap script.

3.3.3. Interix

Interix is a POSIX-compatible subsystem for the Windows NT kernel, providing a
Unix-like environment with a tighter kernel integration than available with
Cygwin. It is part of the Windows Services for Unix package, available for free
for any licensed copy of Windows 2000, XP (not including XP Home), or 2003. SFU
can be downloaded from http://www.microsoft.com/windows/sfu/.

Services for Unix 3.5 has been tested. 3.0 or 3.1 may work, but are not
officially supported. (The main difference in 3.0/3.1 is lack of pthreads, but
other parts of libc may also be lacking.)

Services for Unix Applications (aka SUA) is an integrated component of Windows
Server 2003 R2 (5.2), Windows Vista and Windows Server 2008 (6.0), Windows 7
and Windows Server 2008 R2 (6.1). As of this writing, the SUA's Interix 6.0
(32bit) and 6.1 (64bit) subsystems have been tested. Other versions may work as
well. The Interix 5.x subsystem has not yet been tested with pkgsrc.

3.3.3.1. When installing Interix/SFU

At an absolute minimum, the following packages must be installed from the
Windows Services for Unix 3.5 distribution in order to use pkgsrc:

  * Utilities -> Base Utilities

  * Interix GNU Components -> (all)

  * Remote Connectivity

  * Interix SDK

When using pkgsrc on Interix, DO NOT install the Utilities subcomponent "UNIX
Perl". That is Perl 5.6 without shared module support, installed to /usr/local,
and will only cause confusion. Instead, install Perl 5.8 from pkgsrc (or from a
binary package).

The Remote Connectivity subcomponent "Windows Remote Shell Service" does not
need to be installed, but Remote Connectivity itself should be installed in
order to have a working inetd.

During installation you may be asked whether to enable setuid behavior for
Interix programs, and whether to make pathnames default to case-sensitive.
Setuid should be enabled, and case-sensitivity MUST be enabled. (Without
case-sensitivity, a large number of packages including perl will not build.)

NOTE: Newer Windows service packs change the way binary execution works (via
the Data Execution Prevention feature). In order to use pkgsrc and other
gcc-compiled binaries reliably, a hotfix containing POSIX.EXE, PSXDLL.DLL,
PSXRUN.EXE, and PSXSS.EXE (899522 or newer) must be installed. Hotfixes are
available from Microsoft through a support contract; however, Debian Interix
Port has made most Interix hotfixes available for personal use from http://
www.debian-interix.net/hotfixes/.

In addition to the hotfix noted above, it may be necessary to disable Data
Execution Prevention entirely to make Interix functional. This may happen only
with certain types of CPUs; the cause is not fully understood at this time. If
gcc or other applications still segfault repeatedly after installing one of the
hotfixes note above, the following option can be added to the appropriate
"boot.ini" line on the Windows boot drive: /NoExecute=AlwaysOff (WARNING, this
will disable DEP completely, which may be a security risk if applications are
often run as a user in the Administrators group!)

3.3.3.2. What to do if Interix/SFU is already installed

If SFU is already installed and you wish to alter these settings to work with
pkgsrc, note the following things.

  * To uninstall UNIX Perl, use Add/Remove Programs, select Microsoft Windows
    Services for UNIX, then click Change. In the installer, choose Add or
    Remove, then uncheck Utilities->UNIX Perl.

  * To enable case-sensitivity for the file system, run REGEDIT.EXE, and change
    the following registry key:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel

    Set the DWORD value "obcaseinsensitive" to 0; then reboot.

  * To enable setuid binaries (optional), run REGEDIT.EXE, and change the
    following registry key:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Services for UNIX

    Set the DWORD value "EnableSetuidBinaries" to 1; then reboot.

3.3.3.3. Important notes for using pkgsrc

The package manager (either the pkgsrc "su" user, or the user running
"pkg_add") must be a member of the local Administrators group. Such a user must
also be used to run the bootstrap. This is slightly relaxed from the normal
pkgsrc requirement of "root".

The package manager should use a umask of 002. "make install" will
automatically complain if this is not the case. This ensures that directories
written in /var/db/pkg are Administrators-group writeable.

The popular Interix binary packages from http://www.interopsystems.com/ use an
older version of pkgsrc's pkg_* tools. Ideally, these should NOT be used in
conjunction with pkgsrc. If you choose to use them at the same time as the
pkgsrc packages, ensure that you use the proper pkg_* tools for each type of
binary package.

The TERM setting used for DOS-type console windows (including those invoked by
the csh and ksh startup shortcuts) is "interix". Most systems don't have a
termcap/terminfo entry for it, but the following .termcap entry provides
adequate emulation in most cases:

interix:kP=\E[S:kN=\E[T:kH=\E[U:dc@:DC@:tc=pcansi:


3.3.3.4. Limitations of the Interix platform

Though Interix suffices as a familiar and flexible substitute for a full
Unix-like platform, it has some drawbacks that should be noted for those
desiring to make the most of Interix.

  * X11:

    Interix comes with the standard set of X11R6 client libraries, and can run
    X11 based applications, but it does not come with an X server. Some options
    are StarNet X-Win32, Hummingbird Exceed (available in a trimmed version for
    Interix from Interop Systems as the Interop X Server), and the free X11
    server included with Cygwin.

  * X11 acceleration:

    Because Interix runs in a completely different NT subsystem from Win32
    applications, it does not currently support various X11 protocol extensions
    for acceleration (such as MIT-SHM or DGA). Most interactive applications to
    a local X server will run reasonably fast, but full motion video and other
    graphics intensive applications may require a faster-than-expected CPU.

  * Audio:

    Interix has no native support for audio output. For audio support, pkgsrc
    uses the esound client/server audio system on Interix. Unlike on most
    platforms, the audio/esound package does not contain the esd server
    component. To output audio via an Interix host, the emulators/cygwin_esound
    package must also be installed.

  * CD/DVDs, USB, and SCSI:

    Direct device access is not currently supported in Interix, so it is not
    currently possible to access CD/DVD drives, USB devices, or SCSI devices
    through non-filesystem means. Among other things, this makes it impossible
    to use Interix directly for CD/DVD burning.

  * Tape drives:

    Due to the same limitations as for CD-ROMs and SCSI devices, tape drives
    are also not directly accessible in Interix. However, support is in work to
    make tape drive access possible by using Cygwin as a bridge (similarly to
    audio bridged via Cygwin's esound server).

3.3.3.5. Known issues for pkgsrc on Interix

It is not necessary, in general, to have a "root" user on the Windows system;
any member of the local Administrators group will suffice. However, some
packages currently assume that the user named "root" is the privileged user. To
accommodate these, you may create such a user; make sure it is in the local
group Administrators (or your language equivalent).

pkg_add creates directories of mode 0755, not 0775, in $PKG_DBDIR. For the time
being, install packages as the local Administrator (or your language
equivalent), or run the following command after installing a package to work
around the issue:

# chmod -R g+w $PKG_DBDIR


3.3.4. IRIX

You will need a working C compiler, either gcc or SGI's MIPS and MIPSpro
compiler (cc/c89). Please set the CC environment variable according to your
preference. If you do not have a license for the MIPSpro compiler suite, you
can download a gcc tardist file from http://freeware.sgi.com/.

Please note that you will need IRIX 6.5.17 or higher, as this is the earliest
version of IRIX providing support for if_indextoname(3), if_nametoindex(3),
etc.

At this point in time, pkgsrc only supports one ABI at a time. That is, you
cannot switch between the old 32-bit ABI, the new 32-bit ABI and the 64-bit
ABI. If you start out using "abi=n32", that's what all your packages will be
built with.

Therefore, please make sure that you have no conflicting CFLAGS in your
environment or the mk.conf. Particularly, make sure that you do not try to link
n32 object files with lib64 or vice versa. Check your /etc/compiler.defaults!

If you have the actual pkgsrc tree mounted via NFS from a different host,
please make sure to set WRKOBJDIR to a local directory, as it appears that IRIX
linker occasionally runs into issues when trying to link over a network-mounted
file system.

The bootstrapping process should set all the right options for programs such as
imake(1), but you may want to set some options depending on your local setup.
Please see pkgsrc/mk/defaults/mk.conf and, of course, your compiler's man pages
for details.

If you are using SGI's MIPSPro compiler, please set

PKGSRC_COMPILER= mipspro


in mk.conf. Otherwise, pkgsrc will assume you are using gcc and may end up
passing invalid flags to the compiler. Note that bootstrap should create an
appropriate mk.conf.example by default.

If you have both the MIPSPro compiler chain installed as well as gcc, but want
to make sure that MIPSPro is used, please set your PATH to not include the
location of gcc (often /usr/freeware/bin), and (important) pass the
'--preserve-path' flag.

3.3.5. Linux

Some versions of Linux (for example Debian GNU/Linux) need either libtermcap or
libcurses (libncurses). Installing the distributions libncurses-dev package (or
equivalent) should fix the problem.

pkgsrc supports both gcc (GNU Compiler Collection) and icc (Intel C++
Compiler). gcc is the default. icc 8.0 and 8.1 on i386 have been tested.

To bootstrap using icc, assuming the default icc installation directory:

env ICCBASE=/opt/intel/cc/10.1.008 ./bootstrap --compiler=icc


Note

For icc 8.0 you must add `LDFLAGS=-static-libcxa' to this.

For icc 8.1 you must add `LDFLAGS=-i-static' instead.

For icc 10.1 neither of these appears to be necessary.

Use a value for ICCBASE that corresponds to the directory where icc is
installed. After bootstrapping, set ICCBASE in mk.conf:

ICCBASE= /opt/intel/cc/10.1.008


The pkgsrc default for ICCBASE is /opt/intel_cc_80. This is the default install
directory for icc 8.0. If you are using a more recent version, be sure to set
the correct path explicitly.

pkgsrc uses the static linking method of the runtime libraries provided by icc,
so binaries can be run on other systems which do not have the shared libraries
installed.

Libtool, however, extracts a list of libraries from the ld(1) command run when
linking a C++ shared library and records it, throwing away the -Bstatic and
-Bdynamic options interspersed between the libraries. This means that
libtool-linked C++ shared libraries will have a runtime dependency on the icc
libraries until this is fixed in libtool.

3.3.6. OpenBSD

OpenBSD 5.1 has been tested and supported, other versions may work.

Care should be taken so that the tools that this kit installs do not conflict
with the OpenBSD userland tools. There are several steps:

 1. OpenBSD stores its ports pkg database in /var/db/pkg. It is therefore
    recommended that you choose a different location (e.g. /usr/pkgdb) by using
    the --pkgdbdir option to the bootstrap script.

 2. If you do not intend to use the OpenBSD ports tools, it's probably a good
    idea to move them out of the way to avoid confusion, e.g.

    # cd /usr/sbin
    # mv pkg_add pkg_add.orig
    # mv pkg_create pkg_create.orig
    # mv pkg_delete pkg_delete.orig
    # mv pkg_info pkg_info.orig


 3. An example mk.conf file will be placed in /etc/mk.conf.example file when
    you use the bootstrap script. OpenBSD's make program uses mk.conf as well.
    You can work around this by enclosing all the pkgsrc-specific parts of the
    file with:

    .ifdef BSD_PKG_MK
    # pkgsrc stuff, e.g. insert defaults/mk.conf or similar here
    .else
    # OpenBSD stuff
    .endif


3.3.7. Solaris

Solaris 2.6 through 10 are supported on both x86 and sparc. You will need a
working C compiler. Both gcc 4.5.3 and Sun WorkShop 5 have been tested.

The following packages are required on Solaris 8 for the bootstrap process and
to build packages.

  * SUNWsprot

  * SUNWarc

  * SUNWbtool

  * SUNWtoo

  * SUNWlibm

Please note that the use of GNU binutils on Solaris is not supported, as of
June 2006.

Whichever compiler you use, please ensure the compiler tools and your $prefix
are in your PATH. This includes /usr/ccs/{bin,lib} and e.g. /usr/pkg/
{bin,sbin}.

3.3.7.1. If you are using gcc

It makes life much simpler if you only use the same gcc consistently for
building all packages.

It is recommended that an external gcc be used only for bootstrapping, then
either build gcc from lang/gcc46 or install a binary gcc package, then remove
gcc used during bootstrapping.

Binary packages of gcc can be found through http://www.sunfreeware.com/.

3.3.7.2. If you are using Sun WorkShop

You will need at least the following packages installed (from WorkShop 5.0)

  * SPROcc - Sun WorkShop Compiler C 5.0

  * SPROcpl - Sun WorkShop Compiler C++ 5.0

  * SPROild - Sun WorkShop Incremental Linker

  * SPROlang - Sun WorkShop Compilers common components

You should set the following variables in your mk.conf file:

CC= cc
CXX= CC
CPP= cc -E
CXXCPP= CC -E

Note

The CPP setting might break some packages that use the C preprocessor for
processing things other than C source code.

3.3.7.3. Building 64-bit binaries with SunPro

To build 64-bit packages, you just need to have the following lines in your
mk.conf file:

PKGSRC_COMPILER= sunpro
ABI= 64

Note

This setting has been tested for the SPARC architecture. Intel and AMD machines
need some more work.

3.3.7.4. Common problems

Sometimes, when using libtool, /bin/ksh crashes with a segmentation fault. The
workaround is to use another shell for the configure scripts, for example by
installing shells/bash and adding the following lines to your mk.conf:

CONFIG_SHELL= ${LOCALBASE}/bin/bash
WRAPPER_SHELL= ${LOCALBASE}/bin/bash


Then, rebuild the devel/libtool-base package.

Chapter 4. Using pkgsrc

Table of Contents

4.1. Using binary packages

    4.1.1. Finding binary packages
    4.1.2. Installing binary packages
    4.1.3. Deinstalling packages
    4.1.4. Getting information about installed packages
    4.1.5. Checking for security vulnerabilities in installed packages
    4.1.6. Finding if newer versions of your installed packages are in pkgsrc
    4.1.7. Other administrative functions
    4.1.8. A word of warning

4.2. Building packages from source

    4.2.1. Requirements
    4.2.2. Fetching distfiles
    4.2.3. How to build and install

Basically, there are two ways of using pkgsrc. The first is to only install the
package tools and to use binary packages that someone else has prepared. This
is the "pkg" in pkgsrc. The second way is to install the "src" of pkgsrc, too.
Then you are able to build your own packages, and you can still use binary
packages from someone else.

4.1. Using binary packages

On the ftp.NetBSD.org server and its mirrors, there are collections of binary
packages, ready to be installed. These binary packages have been built using
the default settings for the directories, that is:

  * /usr/pkg for LOCALBASE, where most of the files are installed,

  * /usr/pkg/etc for configuration files,

  * /var for VARBASE, where those files are installed that may change after
    installation.

If you cannot use these directories for whatever reasons (maybe because you're
not root), you cannot use these binary packages, but have to build the packages
yourself, which is explained in Section 3.2, "Bootstrapping pkgsrc".

4.1.1. Finding binary packages

To install binary packages, you first need to know from where to get them. The
first place where you should look is on the main pkgsrc FTP server in the
directory /pub/pkgsrc/packages.

This directory contains binary packages for multiple platforms. First, select
your operating system. (Ignore the directories with version numbers attached to
it, they just exist for legacy reasons.) Then, select your hardware
architecture, and in the third step, the OS version and the "version" of
pkgsrc.

In this directory, you often find a file called bootstrap.tar.gz which contains
the package management tools. If the file is missing, it is likely that your
operating system already provides those tools. Download the file and extract it
in the / directory. It will create the directories /usr/pkg (containing the
tools for managing binary packages) and /var/db/pkg (the database of installed
packages).

4.1.2. Installing binary packages

In the directory from the last section, there is a subdirectory called All,
which contains all the binary packages that are available for the platform,
excluding those that may not be distributed via FTP or CDROM (depending on
which medium you are using).

To install packages directly from an FTP or HTTP server, run the following
commands in a Bourne-compatible shell (be sure to su to root first):

# PATH="/usr/pkg/sbin:$PATH"
# PKG_PATH="ftp://ftp.NetBSD.org/pub/pkgsrc/packages/OPSYS/ARCH/VERSIONS/All"
# export PATH PKG_PATH

Instead of URLs, you can also use local paths, for example if you are
installing from a set of CDROMs, DVDs or an NFS-mounted repository. If you want
to install packages from multiple sources, you can separate them by a semicolon
in PKG_PATH.

After these preparations, installing a package is very easy:

# pkg_add openoffice2
# pkg_add kde-3.5.7
# pkg_add ap2-php5-*

Note that any prerequisite packages needed to run the package in question will
be installed, too, assuming they are present where you install from.

Adding packages might install vulnerable packages. Thus you should run
pkg_admin audit regularly, especially after installing new packages, and verify
that the vulnerabilities are acceptable for your configuration.

After you've installed packages, be sure to have /usr/pkg/bin and /usr/pkg/sbin
in your PATH so you can actually start the just installed program.

4.1.3. Deinstalling packages

To deinstall a package, it does not matter whether it was installed from source
code or from a binary package. The pkg_delete command does not know it anyway.
To delete a package, you can just run pkg_delete package-name. The package name
can be given with or without version number. Wildcards can also be used to
deinstall a set of packages, for example *emacs*. Be sure to include them in
quotes, so that the shell does not expand them before pkg_delete sees them.

The -r option is very powerful: it removes all the packages that require the
package in question and then removes the package itself. For example:

# pkg_delete -r jpeg


will remove jpeg and all the packages that used it; this allows upgrading the
jpeg package.

4.1.4. Getting information about installed packages

The pkg_info shows information about installed packages or binary package
files.

4.1.5. Checking for security vulnerabilities in installed packages

The NetBSD Security-Officer and Packages Groups maintain a list of known
security vulnerabilities to packages which are (or have been) included in
pkgsrc. The list is available from the NetBSD FTP site at ftp://ftp.NetBSD.org/
pub/pkgsrc/distfiles/vulnerabilities.

Through pkg_admin fetch-pkg-vulnerabilities, this list can be downloaded
automatically, and a security audit of all packages installed on a system can
take place.

There are two components to auditing. The first step, pkg_admin
fetch-pkg-vulnerabilities, is for downloading the list of vulnerabilities from
the NetBSD FTP site. The second step, pkg_admin audit, checks to see if any of
your installed packages are vulnerable. If a package is vulnerable, you will
see output similar to the following:

Package samba-2.0.9 has a local-root-shell vulnerability, see
    http://www.samba.org/samba/whatsnew/macroexploit.html

You may wish to have the vulnerabilities file downloaded daily so that it
remains current. This may be done by adding an appropriate entry to the root
users crontab(5) entry. For example the entry

# download vulnerabilities file
0 3 * * * /usr/sbin/pkg_admin fetch-pkg-vulnerabilities >/dev/null 2>&1


will update the vulnerability list every day at 3AM. You may wish to do this
more often than once a day. In addition, you may wish to run the package audit
from the daily security script. This may be accomplished by adding the
following line to /etc/security.local:

/usr/sbin/pkg_admin audit


4.1.6. Finding if newer versions of your installed packages are in pkgsrc

Install pkgtools/lintpkgsrc and run lintpkgsrc with the "-i" argument to check
if your packages are up-to-date, e.g.

% lintpkgsrc -i
...
Version mismatch: 'tcsh' 6.09.00 vs 6.10.00


You can then use make update to update the package on your system and rebuild
any dependencies.

4.1.7. Other administrative functions

The pkg_admin executes various administrative functions on the package system.

4.1.8. A word of warning

Please pay very careful attention to the warnings expressed in the pkg_add(1)
manual page about the inherent dangers of installing binary packages which you
did not create yourself, and the security holes that can be introduced onto
your system by indiscriminate adding of such files.

The same warning of course applies to every package you install from source
when you haven't completely read and understood the source code of the package,
the compiler that is used to build the package and all the other tools that are
involved.

4.2. Building packages from source

After obtaining pkgsrc, the pkgsrc directory now contains a set of packages,
organized into categories. You can browse the online index of packages, or run
make readme from the pkgsrc directory to build local README.html files for all
packages, viewable with any web browser such as www/lynx or www/firefox.

The default prefix for installed packages is /usr/pkg. If you wish to change
this, you should do so by setting LOCALBASE in mk.conf. You should not try to
use multiple different LOCALBASE definitions on the same system (inside a
chroot is an exception).

The rest of this chapter assumes that the package is already in pkgsrc. If it
is not, see Part II, "The pkgsrc developer's guide" for instructions how to
create your own packages.

4.2.1. Requirements

To build packages from source, you need a working C compiler. On NetBSD, you
need to install the "comp" and the "text" distribution sets. If you want to
build X11-related packages, the "xbase" and "xcomp" distribution sets are
required, too.

4.2.2. Fetching distfiles

The first step for building a package is downloading the distfiles (i.e. the
unmodified source). If they have not yet been downloaded, pkgsrc will fetch
them automatically.

If you have all files that you need in the distfiles directory, you don't need
to connect. If the distfiles are on CD-ROM, you can mount the CD-ROM on /cdrom
and add:

DISTDIR=/cdrom/pkgsrc/distfiles

to your mk.conf.

By default a list of distribution sites will be randomly intermixed to prevent
huge load on servers which holding popular packages (for example,
SourceForge.net mirrors). Thus, every time when you need to fetch yet another
distfile all the mirrors will be tried in new (random) order. You can turn this
feature off by setting MASTER_SORT_RANDOM=NO (for PKG_DEVELOPERs it's already
disabled).

You can overwrite some of the major distribution sites to fit to sites that are
close to your own. By setting one or two variables you can modify the order in
which the master sites are accessed. MASTER_SORT contains a whitespace
delimited list of domain suffixes. MASTER_SORT_REGEX is even more flexible, it
contains a whitespace delimited list of regular expressions. It has higher
priority than MASTER_SORT. Have a look at pkgsrc/mk/defaults/mk.conf to find
some examples. This may save some of your bandwidth and time.

You can change these settings either in your shell's environment, or, if you
want to keep the settings, by editing the mk.conf file, and adding the
definitions there.

If a package depends on many other packages (such as meta-pkgs/kde3), the build
process may alternate between periods of downloading source, and compiling. To
ensure you have all the source downloaded initially you can run the command:

% make fetch-list | sh

which will output and run a set of shell commands to fetch the necessary files
into the distfiles directory. You can also choose to download the files
manually.

4.2.3. How to build and install

Once the software has downloaded, any patches will be applied, then it will be
compiled for you. This may take some time depending on your computer, and how
many other packages the software depends on and their compile time.

Note

If using bootstrap or pkgsrc on a non-NetBSD system, use the pkgsrc bmake
command instead of "make" in the examples in this guide.

For example, type

% cd misc/figlet
% make


at the shell prompt to build the various components of the package.

The next stage is to actually install the newly compiled program onto your
system. Do this by entering:

% make install


while you are still in the directory for whatever package you are installing.

Installing the package on your system may require you to be root. However,
pkgsrc has a just-in-time-su feature, which allows you to only become root for
the actual installation step.

That's it, the software should now be installed and setup for use. You can now
enter:

% make clean


to remove the compiled files in the work directory, as you shouldn't need them
any more. If other packages were also added to your system (dependencies) to
allow your program to compile, you can tidy these up also with the command:

% make clean-depends


Taking the figlet utility as an example, we can install it on our system by
building as shown in Appendix B, Build logs.

The program is installed under the default root of the packages tree - /usr/
pkg. Should this not conform to your tastes, set the LOCALBASE variable in your
environment, and it will use that value as the root of your packages tree. So,
to use /usr/local, set LOCALBASE=/usr/local in your environment. Please note
that you should use a directory which is dedicated to packages and not shared
with other programs (i.e., do not try and use LOCALBASE=/usr). Also, you should
not try to add any of your own files or directories (such as src/, obj/, or
pkgsrc/) below the LOCALBASE tree. This is to prevent possible conflicts
between programs and other files installed by the package system and whatever
else may have been installed there.

Some packages look in mk.conf to alter some configuration options at build
time. Have a look at pkgsrc/mk/defaults/mk.conf to get an overview of what will
be set there by default. Environment variables such as LOCALBASE can be set in
mk.conf to save having to remember to set them each time you want to use
pkgsrc.

Occasionally, people want to "look under the covers" to see what is going on
when a package is building or being installed. This may be for debugging
purposes, or out of simple curiosity. A number of utility values have been
added to help with this.

 1. If you invoke the make(1) command with PKG_DEBUG_LEVEL=2, then a huge
    amount of information will be displayed. For example,

    make patch PKG_DEBUG_LEVEL=2

    will show all the commands that are invoked, up to and including the "patch
    " stage.

 2. If you want to know the value of a certain make(1) definition, then the
    VARNAME definition should be used, in conjunction with the show-var target.
    e.g. to show the expansion of the make(1) variable LOCALBASE:

    % make show-var VARNAME=LOCALBASE
    /usr/pkg
    %


If you want to install a binary package that you've either created yourself
(see next section), that you put into pkgsrc/packages manually or that is
located on a remote FTP server, you can use the "bin-install" target. This
target will install a binary package - if available - via pkg_add(1), else do a
make package. The list of remote FTP sites searched is kept in the variable
BINPKG_SITES, which defaults to ftp.NetBSD.org. Any flags that should be added
to pkg_add(1) can be put into BIN_INSTALL_FLAGS. See pkgsrc/mk/defaults/mk.conf
for more details.

A final word of warning: If you set up a system that has a non-standard setting
for LOCALBASE, be sure to set that before any packages are installed, as you
cannot use several directories for the same purpose. Doing so will result in
pkgsrc not being able to properly detect your installed packages, and fail
miserably. Note also that precompiled binary packages are usually built with
the default LOCALBASE of /usr/pkg, and that you should not install any if you
use a non-standard LOCALBASE.

Chapter 5. Configuring pkgsrc

Table of Contents

5.1. General configuration
5.2. Variables affecting the build process
5.3. Variables affecting the installation process
5.4. Selecting and configuring the compiler

    5.4.1. Selecting the compiler
    5.4.2. Additional flags to the compiler (CFLAGS)
    5.4.3. Additional flags to the linker (LDFLAGS)

5.5. Developer/advanced settings
5.6. Selecting Build Options

The whole pkgsrc system is configured in a single file, usually called mk.conf.
In which directory pkgsrc looks for that file depends on the installation. On
NetBSD, when you use make(1) from the base system, it is in the directory /etc
/. In all other cases the default location is ${PREFIX}/etc/, depending on
where you told the bootstrap program to install the binary packages.

During the bootstrap, an example configuration file is created. To use that,
you have to create the directory ${PREFIX}/etc and copy the example file there.

The format of the configuration file is that of the usual BSD-style Makefiles.
The whole pkgsrc configuration is done by setting variables in this file. Note
that you can define all kinds of variables, and no special error checking (for
example for spelling mistakes) takes place, so you have to try it out to see if
it works.

5.1. General configuration

In this section, you can find some variables that apply to all pkgsrc packages.
A complete list of the variables that can be configured by the user is
available in mk/defaults/mk.conf, together with some comments that describe
each variable's intent.

  * LOCALBASE: Where packages will be installed. The default is /usr/pkg. Do
    not mix binary packages with different LOCALBASEs!

  * CROSSBASE: Where "cross" category packages will be installed. The default
    is ${LOCALBASE}/cross.

  * X11BASE: Where X11 is installed on the system. The default is /usr/X11R6.

  * DISTDIR: Where to store the downloaded copies of the original source
    distributions used for building pkgsrc packages. The default is $
    {PKGSRCDIR}/distfiles.

  * PKG_DBDIR: Where the database about installed packages is stored. The
    default is /var/db/pkg.

  * MASTER_SITE_OVERRIDE: If set, override the packages' MASTER_SITES with this
    value.

  * MASTER_SITE_BACKUP: Backup location(s) for distribution files and patch
    files if not found locally or in ${MASTER_SITES} or ${PATCH_SITES}
    respectively. The defaults are ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/$
    {DIST_SUBDIR}/ and ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/$
    {DIST_SUBDIR}/.

  * BINPKG_SITES: List of sites carrying binary pkgs. rel and arch are replaced
    with OS release ("2.0", etc.) and architecture ("mipsel", etc.).

  * ACCEPTABLE_LICENSES: List of acceptable licenses. License names are
    case-sensitive. Whenever you try to build a package whose license is not in
    this list, you will get an error message. If the license condition is
    simple enough, the error message will include specific instructions on how
    to change this variable.

5.2. Variables affecting the build process

XXX

  * PACKAGES: The top level directory for the binary packages. The default is $
    {PKGSRCDIR}/packages.

  * WRKOBJDIR: The top level directory where, if defined, the separate working
    directories will get created, and symbolically linked to from ${WRKDIR}
    (see below). This is useful for building packages on several architectures,
    then ${PKGSRCDIR} can be NFS-mounted while ${WRKOBJDIR} is local to every
    architecture. (It should be noted that PKGSRCDIR should not be set by the
    user ? it is an internal definition which refers to the root of the pkgsrc
    tree. It is possible to have many pkgsrc tree instances.)

  * LOCALPATCHES: Directory for local patches that aren't part of pkgsrc. See
    Section 11.3, "patches/*" for more information.

  * PKGMAKECONF: Location of the mk.conf file used by a package's BSD-style
    Makefile. If this is not set, MAKECONF is set to /dev/null to avoid picking
    up settings used by builds in /usr/src.

  * DEPENDS_TARGET: By default, dependencies are only installed, and no binary
    package is created for them. You can set this variable to package to
    automatically create binary packages after installing dependencies.

5.3. Variables affecting the installation process

Most packages support installation into a subdirectory of WRKDIR. This allows a
package to be built, before the actual filesystem is touched. DESTDIR support
exists in two variations:

  * Basic DESTDIR support means that the package installation and packaging is
    still run as root.

  * Full DESTDIR support can run the complete build, installation and packaging
    as normal user. Root privileges are only needed to add packages.

DESTDIR support is now the default. To switch back to non-DESTDIR, you can set
USE_DESTDIR=no; this setting will be deprecated though, so it's preferable to
convert a package to DESTDIR instead.

DESTDIR support changes the behaviour of various targets slightly. To install a
package after building it, use package-install. package and install don't do
that any longer. package-install can be used as DEPENDS_TARGET. bin-install
will ask for the root password to install the package and fail, package-install
will ask again.

With basic DESTDIR support, make clean needs to be run as root.

Considering the foo/bar package, DESTDIR full support can be tested using the
following commands

$ id
uid=1000(myusername) gid=100(users) groups=100(users),0(wheel)
$ mkdir $HOME/packages
$ cd $PKGSRCDIR/foo/bar

Verify DESTDIR full support, no root privileges should be needed

$ make USE_DESTDIR=yes install

Create a package without root privileges

$ make USE_DESTDIR=yes PACKAGES=$HOME/packages package

For the following command, you must be able to gain root privileges using su(1)

$ make USE_DESTDIR=yes PACKAGES=$HOME/packages package-install

Then, as a simple user

$ make clean

5.4. Selecting and configuring the compiler

5.4.1. Selecting the compiler

By default, pkgsrc will use GCC to build packages. This may be overridden by
setting the following variables in /etc/mk.conf:

PKGSRC_COMPILER:

    This is a list of values specifying the chain of compilers to invoke when
    building packages. Valid values are:

      * distcc: distributed C/C++ (chainable)

      * ccache: compiler cache (chainable)

      * gcc: GNU C/C++ Compiler

      * mipspro: Silicon Graphics, Inc. MIPSpro (n32/n64)

      * mipspro: Silicon Graphics, Inc. MIPSpro (o32)

      * sunpro: Sun Microsystems, Inc. WorkShip/Forte/Sun ONE Studio

    The default is "gcc". You can use ccache and/or distcc with an appropriate
    PKGSRC_COMPILER setting, e.g. "ccache gcc". This variable should always be
    terminated with a value for a real compiler. Note that only one real
    compiler should be listed (e.g. "sunpro gcc" is not allowed).

GCC_REQD:

    This specifies the minimum version of GCC to use when building packages. If
    the system GCC doesn't satisfy this requirement, then pkgsrc will build and
    install one of the GCC packages to use instead.

5.4.2. Additional flags to the compiler (CFLAGS)

If you wish to set the CFLAGS variable, please make sure to use the += operator
instead of the = operator:

CFLAGS+= -your -flags

Using CFLAGS= (i.e. without the "+") may lead to problems with packages that
need to add their own flags. You may want to take a look at the devel/cpuflags
package if you're interested in optimization specifically for the current CPU.

5.4.3. Additional flags to the linker (LDFLAGS)

If you want to pass flags to the linker, both in the configure step and the
build step, you can do this in two ways. Either set LDFLAGS or LIBS. The
difference between the two is that LIBS will be appended to the command line,
while LDFLAGS come earlier. LDFLAGS is pre-loaded with rpath settings for ELF
machines depending on the setting of USE_IMAKE or the inclusion of mk/
x11.buildlink3.mk. As with CFLAGS, if you do not wish to override these
settings, use the += operator:

LDFLAGS+= -your -linkerflags

5.5. Developer/advanced settings

XXX

  * PKG_DEVELOPER: Run some sanity checks that package developers want:

      o make sure patches apply with zero fuzz

      o run check-shlibs to see that all binaries will find their shared libs.

  * PKG_DEBUG_LEVEL: The level of debugging output which is displayed whilst
    making and installing the package. The default value for this is 0, which
    will not display the commands as they are executed (normal, default, quiet
    operation); the value 1 will display all shell commands before their
    invocation, and the value 2 will display both the shell commands before
    their invocation, and their actual execution progress with set -x will be
    displayed.

5.6. Selecting Build Options

Some packages have build time options, usually to select between different
dependencies, enable optional support for big dependencies or enable
experimental features.

To see which options, if any, a package supports, and which options are
mutually exclusive, run make show-options, for example:

    The following options are supported by this package:
        ssl Enable SSL support.
    Exactly one of the following gecko options is required:
        firefox Use firefox as gecko rendering engine.
        mozilla Use mozilla as gecko rendering engine.
    At most one of the following database options may be selected:
        mysql Enable support for MySQL database.
        pgsql Enable support for PostgreSQL database.

    These options are enabled by default: firefox
    These options are currently enabled: mozilla ssl

The following variables can be defined in mk.conf to select which options to
enable for a package: PKG_DEFAULT_OPTIONS, which can be used to select or
disable options for all packages that support them, and PKG_OPTIONS.pkgbase,
which can be used to select or disable options specifically for package pkgbase
. Options listed in these variables are selected, options preceded by "-" are
disabled. A few examples:

$ grep "PKG.*OPTION" mk.conf
PKG_DEFAULT_OPTIONS= -arts -dvdread -esound
PKG_OPTIONS.kdebase= debug -sasl
PKG_OPTIONS.apache= suexec

It is important to note that options that were specifically suggested by the
package maintainer must be explicitly removed if you do not wish to include the
option. If you are unsure you can view the current state with make show-options
.

The following settings are consulted in the order given, and the last setting
that selects or disables an option is used:

 1. the default options as suggested by the package maintainer

 2. the options implied by the settings of legacy variables (see below)

 3. PKG_DEFAULT_OPTIONS

 4. PKG_OPTIONS.pkgbase

For groups of mutually exclusive options, the last option selected is used, all
others are automatically disabled. If an option of the group is explicitly
disabled, the previously selected option, if any, is used. It is an error if no
option from a required group of options is selected, and building the package
will fail.

Before the options framework was introduced, build options were selected by
setting a variable (often named USE_FOO) in mk.conf for each option. To ease
transition to the options framework for the user, these legacy variables are
converted to the appropriate options setting (PKG_OPTIONS.pkgbase)
automatically. A warning is issued to prompt the user to update mk.conf to use
the options framework directly. Support for the legacy variables will be
removed eventually.

Chapter 6. Creating binary packages

Table of Contents

6.1. Building a single binary package
6.2. Settings for creation of binary packages

6.1. Building a single binary package

Once you have built and installed a package, you can create a binary package
which can be installed on another system with pkg_add(1). This saves having to
build the same package on a group of hosts and wasting CPU time. It also
provides a simple means for others to install your package, should you
distribute it.

To create a binary package, change into the appropriate directory in pkgsrc,
and run make package:

# cd misc/figlet
# make package


This will build and install your package (if not already done), and then build
a binary package from what was installed. You can then use the pkg_* tools to
manipulate it. Binary packages are created by default in /usr/pkgsrc/packages,
in the form of a gzipped tar file. See Section B.2, "Packaging figlet" for a
continuation of the above misc/figlet example.

See Chapter 21, Submitting and Committing for information on how to submit such
a binary package.

6.2. Settings for creation of binary packages

See Section 17.17, "Other helpful targets".

Chapter 7. Creating binary packages for everything in pkgsrc (bulk builds)

Table of Contents

7.1. Think first, build later
7.2. Requirements of a bulk build
7.3. Running an old-style bulk build

    7.3.1. Configuration
    7.3.2. Other environmental considerations
    7.3.3. Operation
    7.3.4. What it does
    7.3.5. Disk space requirements
    7.3.6. Setting up a sandbox for chrooted builds
    7.3.7. Building a partial set of packages
    7.3.8. Uploading results of a bulk build

7.4. Running a pbulk-style bulk build

    7.4.1. Preparation
    7.4.2. Configuration

7.5. Creating a multiple CD-ROM packages collection

    7.5.1. Example of cdpack

When you have multiple machines that should run the same packages, it is wasted
time if they all build their packages themselves from source. There are two
ways of getting a set of binary packages: The old bulk build system, or the new
(as of 2007) parallel bulk build (pbulk) system. This chapter describes how to
set them up so that the packages are most likely to be usable later.

7.1. Think first, build later

Since a bulk build takes several days or even weeks to finish, you should think
about the setup before you start everything. Pay attention to at least the
following points:

  * If you want to upload the binary packages to ftp.NetBSD.org, make sure the
    setup complies to the requirements for binary packages:

      o To end up on ftp.NetBSD.org, the packages must be built by a NetBSD
        developer on a trusted machine (that is, where you and only you have
        root access).

      o Packages on ftp.NetBSD.org should only be created from the stable
        branches (like 2009Q1), so that users browsing the available
        collections can see at a glance how old the packages are.

      o The packages must be built as root, since some packages require set-uid
        binaries at runtime, and creating those packages as unprivileged user
        doesn't work well at the moment.

  * Make sure that the bulk build cannot break anything in your system. Most
    bulk builds run as root, so they should be run at least in a chroot
    environment or something even more restrictive, depending on what the
    operating system provides. There have been numerous cases where certain
    packages tried to install files outside the LOCALBASE or wanted to edit
    some files in /etc. Furthermore, the bulk builds install and deinstall
    packages in /usr/pkg (or whatever LOCALBASE is) during their operation, so
    be sure that you don't need any package during the build.

7.2. Requirements of a bulk build

A complete bulk build requires lots of disk space. Some of the disk space can
be read-only, some other must be writable. Some can be on remote filesystems
(such as NFS) and some should be local. Some can be temporary filesystems,
others must survive a sudden reboot.

  * 10 GB for the distfiles (read-write, remote, temporary)

  * 10 GB for the binary packages (read-write, remote, permanent)

  * 400 MB for the pkgsrc tree (read-only, remote, permanent)

  * 5 GB for LOCALBASE (read-write, local, temporary for pbulk, permanent for
    old-bulk)

  * 5 GB for the log files (read-write, remote, permanent)

  * 5 GB for temporary files (read-write, local, temporary)

7.3. Running an old-style bulk build

Note

There are two ways of doing a bulk build. The old-style one and the new-style "
pbulk". The latter is the recommended way.

7.3.1. Configuration

7.3.1.1. build.conf

The build.conf file is the main configuration file for bulk builds. You can
configure how your copy of pkgsrc is kept up to date, how the distfiles are
downloaded, how the packages are built and how the report is generated. You can
find an annotated example file in pkgsrc/mk/bulk/build.conf-example. To use it,
copy build.conf-example to build.conf and edit it, following the comments in
that file.

7.3.1.2. mk.conf

You may want to set variables in mk.conf. Look at pkgsrc/mk/defaults/mk.conf
for details of the default settings. You will want to ensure that
ACCEPTABLE_LICENSES meet your local policy. As used in this example,
SKIP_LICENSE_CHECK=yes completely bypasses the license check.

PACKAGES?= ${_PKGSRCDIR}/packages/${MACHINE_ARCH}
WRKOBJDIR?= /usr/tmp/pkgsrc # build here instead of in pkgsrc
BSDSRCDIR= /usr/src
BSDXSRCDIR= /usr/xsrc # for x11/xservers
OBJHOSTNAME?= yes # use work.`hostname`
FAILOVER_FETCH= yes # insist on the correct checksum
PKG_DEVELOPER?= yes
SKIP_LICENSE_CHECK= yes

Some options that are especially useful for bulk builds can be found at the top
lines of the file mk/bulk/bsd.bulk-pkg.mk. The most useful options of these are
briefly described here.

  * If you are on a slow machine, you may want to set USE_BULK_BROKEN_CHECK to
    "no".

  * If you are doing bulk builds from a read-only copy of pkgsrc, you have to
    set BULKFILESDIR to the directory where all log files are created.
    Otherwise the log files are created in the pkgsrc directory.

  * Another important variable is BULK_PREREQ, which is a list of packages that
    should be always available while building other packages.

Some other options are scattered in the pkgsrc infrastructure:

  * ALLOW_VULNERABLE_PACKAGES should be set to yes. The purpose of the bulk
    builds is creating binary packages, no matter if they are vulnerable or
    not. Leaving this variable unset would prevent the bulk build system from
    even trying to build them, so possible building errors would not show up.

  * CHECK_FILES (pkgsrc/mk/check/check-files.mk) can be set to "yes" to check
    that the installed set of files matches the PLIST.

  * CHECK_INTERPRETER (pkgsrc/mk/check/check-interpreter.mk) can be set to "yes
    " to check that the installed "#!"-scripts will find their interpreter.

  * PKGSRC_RUN_TEST can be set to "yes" to run each package's self-test before
    installing it. Note that some packages make heavy use of "good" random
    numbers, so you need to assure that the machine on which you are doing the
    bulk builds is not completely idle. Otherwise some test programs will seem
    to hang, while they are just waiting for new random data to be available.

7.3.1.3. pre-build.local

It is possible to configure the bulk build to perform certain site-specific
tasks at the end of the pre-build stage. If the file pre-build.local exists in
/usr/pkgsrc/mk/bulk, it will be executed (as a sh(1) script) at the end of the
usual pre-build stage. An example use of pre-build.local is to have the line:

echo "I do not have enough disk space to build this pig." \
        > misc/openoffice/$BROKENF

to prevent the system from trying to build a particular package which requires
nearly 3 GB of disk space.

7.3.2. Other environmental considerations

As /usr/pkg will be completely deleted at the start of bulk builds, make sure
your login shell is placed somewhere else. Either drop it into /usr/local/bin
(and adjust your login shell in the passwd file), or (re-)install it via
pkg_add(1) from /etc/rc.local, so you can login after a reboot (remember that
your current process won't die if the package is removed, you just can't start
any new instances of the shell any more). Also, if you use NetBSD earlier than
1.5, or you still want to use the pkgsrc version of ssh for some reason, be
sure to install ssh before starting it from rc.local:

(cd /usr/pkgsrc/security/ssh && make bulk-install)
if [ -f /usr/pkg/etc/rc.d/sshd ]; then
  /usr/pkg/etc/rc.d/sshd
fi

Not doing so will result in you being not able to log in via ssh after the bulk
build is finished or if the machine gets rebooted or crashes. You have been
warned! :)

7.3.3. Operation

Make sure you don't need any of the packages still installed.

Warning

During the bulk build, all packages, their configuration files and some more
files from /var, /home and possibly other locations will be removed! So don't
run a bulk build with privileges that might harm your system.

Be sure to remove all other things that might interfere with builds, like some
libs installed in /usr/local, etc. then become root and type:

# cd /usr/pkgsrc
# sh mk/bulk/build


If for some reason your last build didn't complete (power failure, system
panic, ...), you can continue it by running:

# sh mk/bulk/build restart

At the end of the bulk build, you will get a summary via mail, and find build
logs in the directory specified by FTP in the build.conf file.

7.3.4. What it does

The bulk builds consist of three steps:

1. pre-build

    The script updates your pkgsrc tree via (anon)cvs, then cleans out any
    broken distfiles, and removes all packages installed.

2. the bulk build

    This is basically "make bulk-package" with an optimised order in which
    packages will be built. Packages that don't require other packages will be
    built first, and packages with many dependencies will be built later.

3. post-build

    Generates a report that's placed in the directory specified in the
    build.conf file named broken.html, a short version of that report will also
    be mailed to the build's admin.

During the build, a list of broken packages will be compiled in /usr/pkgsrc
/.broken (or .../.broken.${MACHINE} if OBJMACHINE is set), individual build
logs of broken builds can be found in the package's directory. These files are
used by the bulk-targets to mark broken builds to not waste time trying to
rebuild them, and they can be used to debug these broken package builds later.

7.3.5. Disk space requirements

Currently, roughly the following requirements are valid for NetBSD 2.0/i386:

  * 10 GB - distfiles (NFS ok)

  * 8 GB - full set of all binaries (NFS ok)

  * 5 GB - temp space for compiling (local disk recommended)

Note that all pkgs will be de-installed as soon as they are turned into a
binary package, and that sources are removed, so there is no excessively huge
demand to disk space. Afterwards, if the package is needed again, it will be
installed via pkg_add(1) instead of building again, so there are no cycles
wasted by recompiling.

7.3.6. Setting up a sandbox for chrooted builds

If you don't want all the packages nuked from a machine (rendering it useless
for anything but pkg compiling), there is the possibility of doing the package
bulk build inside a chroot environment.

The first step is to set up a chroot sandbox, e.g. /usr/sandbox. This can be
done by using null mounts, or manually.

There is a shell script called mksandbox installed by the pkgtools/mksandbox
package, which will set up the sandbox environment using null mounts. It will
also create a script called sandbox in the root of the sandbox environment,
which will allow the null mounts to be activated using the sandbox mount
command and deactivated using the sandbox umount command.

To set up a sandbox environment by hand, after extracting all the sets from a
NetBSD installation or doing a make distribution DESTDIR=/usr/sandbox in /usr/
src/etc, be sure the following items are present and properly configured:

 1. Kernel

    # cp /netbsd /usr/sandbox

 2. /dev/*

    # cd /usr/sandbox/dev ; sh MAKEDEV all

 3. /etc/resolv.conf (for security/smtpd and mail):

    # cp /etc/resolv.conf /usr/sandbox/etc

 4. Working(!) mail config (hostname, sendmail.cf):

    # cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail

 5. /etc/localtime (for security/smtpd):

    # ln -sf /usr/share/zoneinfo/UTC /usr/sandbox/etc/localtime

 6. /usr/src (system sources, e. g. for sysutils/aperture):

    # ln -s ../disk1/cvs .
              # ln -s cvs/src-2.0 src

 7. Create /var/db/pkg (not part of default install):

    # mkdir /usr/sandbox/var/db/pkg

 8. Create /usr/pkg (not part of default install):

    # mkdir /usr/sandbox/usr/pkg

 9. Checkout pkgsrc via cvs into /usr/sandbox/usr/pkgsrc:

    # cd /usr/sandbox/usr
    # cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P pkgsrc


    Do not mount/link this to the copy of your pkgsrc tree you do development
    in, as this will likely cause problems!

10. Make /usr/sandbox/usr/pkgsrc/packages and .../distfiles point somewhere
    appropriate. NFS- and/or nullfs-mounts may come in handy!

11. Edit mk.conf, see Section 7.3.1.2, "mk.conf".

12. Adjust mk/bulk/build.conf to suit your needs.

When the chroot sandbox is set up, you can start the build with the following
steps:

# cd /usr/sandbox/usr/pkgsrc
# sh mk/bulk/do-sandbox-build


This will just jump inside the sandbox and start building. At the end of the
build, mail will be sent with the results of the build. Created binary pkgs
will be in /usr/sandbox/usr/pkgsrc/packages (wherever that points/mounts to/
from).

7.3.7. Building a partial set of packages

In addition to building a complete set of all packages in pkgsrc, the pkgsrc/mk
/bulk/build script may be used to build a subset of the packages contained in
pkgsrc. By setting SPECIFIC_PKGS in mk.conf, the variables

  * SITE_SPECIFIC_PKGS

  * HOST_SPECIFIC_PKGS

  * GROUP_SPECIFIC_PKGS

  * USER_SPECIFIC_PKGS

will define the set of packages which should be built. The bulk build code will
also include any packages which are needed as dependencies for the explicitly
listed packages.

One use of this is to do a bulk build with SPECIFIC_PKGS in a chroot sandbox
periodically to have a complete set of the binary packages needed for your site
available without the overhead of building extra packages that are not needed.

7.3.8. Uploading results of a bulk build

This section describes how pkgsrc developers can upload binary pkgs built by
bulk builds to ftp.NetBSD.org.

If you would like to automatically create checksum files for the binary
packages you intend to upload, remember to set MKSUMS=yes in your mk/bulk/
build.conf.

If you would like to PGP sign the checksum files (highly recommended!),
remember to set SIGN_AS=username@NetBSD.org in your mk/bulk/build.conf. This
will prompt you for your GPG password to sign the files before uploading
everything.

Then, make sure that you have RSYNC_DST set properly in your mk/bulk/build.conf
file, i.e. adjust it to something like one of the following:

RSYNC_DST=ftp.NetBSD.org:/pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy/upload

Please use appropriate values for "20xxQy" (the branch), "a.b.c" (the OS
version) and "arch" here. If your login on ftp.NetBSD.org is different from
your local login, write your login directly into the variable, e.g. my local
account is "feyrer", but for my login "hubertf", I use:

RSYNC_DST=hubertf@ftp.NetBSD.org:/pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy/upload

A separate upload directory is used here to allow "closing" the directory
during upload. To do so, run the following command on ftp.NetBSD.org next:

nbftp% mkdir -p -m 750 /pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy/upload

Before uploading the binary pkgs, ssh authentication needs to be set up. This
example shows how to set up temporary keys for the root account inside the
sandbox (assuming that no keys should be present there usually):

# chroot /usr/sandbox
chroot-# rm $HOME/.ssh/id-dsa*
chroot-# ssh-keygen -t rsa
chroot-# cat $HOME/.ssh/id-rsa.pub


Now take the output of id-rsa.pub and append it to your ~/.ssh/authorized_keys
file on ftp.NetBSD.org. You should remove the key after the upload is done!

Next, test if your ssh connection really works:

chroot-# ssh ftp.NetBSD.org date

Use "-l yourNetBSDlogin" here as appropriate!

Now after all this works, you can exit the sandbox and start the upload:

chroot-# exit
# cd /usr/sandbox/usr/pkgsrc
# sh mk/bulk/do-sandbox-upload


The upload process may take quite some time. Use ls(1) or du(1) on the FTP
server to monitor progress of the upload. The upload script will take care of
not uploading restricted packages.

After the upload has ended, first thing is to revoke ssh access:

nbftp% vi ~/.ssh/authorized_keys
      Gdd:x!

Use whatever is needed to remove the key you've entered before! Last, move the
uploaded packages out of the upload directory to have them accessible to
everyone:

nbftp% cd /pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy
nbftp% mv upload/* .
nbftp% rmdir upload
nbftp% chgrp -R netbsd .
nbftp% find . -type d | xargs chmod 775


7.4. Running a pbulk-style bulk build

Running a pbulk-style bulk build works roughly as follows:

  * First, build the pbulk infrastructure in a fresh pkgsrc location.

  * Then, build each of the packages from a clean installation directory using
    the infrastructure.

7.4.1. Preparation

First, you need to create a pkgsrc installation for the pbulk infrastructure.
No matter on which platform you are (even on NetBSD), you should bootstrap into
its own directory. Let's take the directory /usr/pbulk or $HOME/pbulk for it.
This installation will be bootstrapped and all the tools that are required for
the bulk build will be installed there.

$ cd /usr/pkgsrc
$ ./bootstrap/bootstrap --prefix=/usr/pbulk --varbase=/usr/pbulk/var --workdir=/tmp/pbulk-bootstrap
$ rm -rf /tmp/pbulk-bootstrap

Now the basic environment for the pbulk infrastructure is installed. The
specific tools are still missing. This is a good time to edit the pkgsrc
configuration file /usr/pbulk/etc/mk.conf to fit your needs. Typical things you
might set now are:

  * PKG_DEVELOPER=yes, to enable many consistency checks,

  * WRKOBJDIR=/tmp/pbulk-outer, to keep /usr/pkgsrc free from any
    modifications,

  * DISTDIR=/distfiles, to have only one directory in which all distfiles (for
    the infrastructure and for the actual packages) are downloaded,

  * ACCEPTABLE_LICENSES+=..., to select some licenses additional to the usual
    Free/Open Source licenses that are acceptable to you,

  * SKIP_LICENSE_CHECK=yes, to bypass the license checks.

Now you are ready to build the rest of the pbulk infrastructure.

$ cd pkgtools/pbulk
$ /usr/pbulk/bin/bmake install
$ rm -rf /tmp/pbulk-outer

Now the pbulk infrastructure is built and installed. It still needs to be
configured, and after some more preparation, we will be able to start the real
bulk build.

7.4.2. Configuration

TODO; see pkgsrc/doc/HOWTO-pbulk for more information.

TODO: continue writing

7.5. Creating a multiple CD-ROM packages collection

After your pkgsrc bulk-build has completed, you may wish to create a CD-ROM set
of the resulting binary packages to assist in installing packages on other
machines. The pkgtools/cdpack package provides a simple tool for creating the
ISO 9660 images. cdpack arranges the packages on the CD-ROMs in a way that
keeps all the dependencies for a given package on the same CD as that package.

7.5.1. Example of cdpack

Complete documentation for cdpack is found in the cdpack(1) man page. The
following short example assumes that the binary packages are left in /usr/
pkgsrc/packages/All and that sufficient disk space exists in /u2 to hold the
ISO 9660 images.

# mkdir /u2/images
# pkg_add /usr/pkgsrc/packages/All/cdpack
# cdpack /usr/pkgsrc/packages/All /u2/images


If you wish to include a common set of files (COPYRIGHT, README, etc.) on each
CD in the collection, then you need to create a directory which contains these
files. e.g.

# mkdir /tmp/common
# echo "This is a README" > /tmp/common/README
# echo "Another file" > /tmp/common/COPYING
# mkdir /tmp/common/bin
# echo "#!/bin/sh" > /tmp/common/bin/myscript
# echo "echo Hello world" >> /tmp/common/bin/myscript
# chmod 755 /tmp/common/bin/myscript


Now create the images:

# cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images

Each image will contain README, COPYING, and bin/myscript in their root
directories.

Chapter 8. Directory layout of the installed files

Table of Contents

8.1. File system layout in ${LOCALBASE}
8.2. File system layout in ${VARBASE}

The files that are installed by pkgsrc are organized in a way that is similar
to what you find in the /usr directory of the base system. But some details are
different. This is because pkgsrc initially came from FreeBSD and had adopted
its file system hierarchy. Later it was largely influenced by NetBSD. But no
matter which operating system you are using pkgsrc with, you can expect the
same layout for pkgsrc.

There are mainly four root directories for pkgsrc, which are all configurable
in the bootstrap/bootstrap script. When pkgsrc has been installed as root, the
default locations are:

LOCALBASE= /usr/pkg
PKG_SYSCONFBASE= /usr/pkg/etc
VARBASE= /var
PKG_DBDIR= /var/db/pkg

In unprivileged mode (when pkgsrc has been installed as any other user), the
default locations are:

LOCALBASE= ${HOME}/pkg
PKG_SYSCONFBASE= ${HOME}/pkg/etc
VARBASE= ${HOME}/pkg/var
PKG_DBDIR= ${HOME}/pkg/var/db/pkg

What these four directories are for, and what they look like is explained
below.

  * LOCALBASE corresponds to the /usr directory in the base system. It is the "
    main" directory where the files are installed and contains the well-known
    subdirectories like bin, include, lib, share and sbin.

  * VARBASE corresponds to /var in the base system. Some programs (especially
    games, network daemons) need write access to it during normal operation.

  * PKG_SYSCONFDIR corresponds to /etc in the base system. It contains
    configuration files of the packages, as well as pkgsrc's mk.conf itself.

8.1. File system layout in ${LOCALBASE}

The following directories exist in a typical pkgsrc installation in $
{LOCALBASE}.

bin

    Contains executable programs that are intended to be directly used by the
    end user.

emul

    Contains files for the emulation layers of various other operating systems,
    especially for NetBSD.

etc (the usual location of ${PKG_SYSCONFDIR})

    Contains the configuration files.

include

    Contains headers for the C and C++ programming languages.

info

    Contains GNU info files of various packages.

lib

    Contains shared and static libraries.

libdata

    Contains data files that don't change after installation. Other data files
    belong into ${VARBASE}.

libexec

    Contains programs that are not intended to be used by end users, such as
    helper programs or network daemons.

libexec/cgi-bin

    Contains programs that are intended to be executed as CGI scripts by a web
    server.

man (the usual value of ${PKGMANDIR})

    Contains brief documentation in form of manual pages.

sbin

    Contains programs that are intended to be used only by the super-user.

share

    Contains platform-independent data files that don't change after
    installation.

share/doc

    Contains documentation files provided by the packages.

share/examples

    Contains example files provided by the packages. Among others, the original
    configuration files are saved here and copied to ${PKG_SYSCONFDIR} during
    installation.

share/examples/rc.d

    Contains the original files for rc.d scripts.

var (the usual location of ${VARBASE})

    Contains files that may be modified after installation.

8.2. File system layout in ${VARBASE}

db/pkg (the usual location of ${PKG_DBDIR})

    Contains information about the currently installed packages.

games

    Contains highscore files.

log

    Contains log files.

run

    Contains informational files about daemons that are currently running.

Chapter 9. Frequently Asked Questions

Table of Contents

9.1. Are there any mailing lists for pkg-related discussion?
9.2. Where's the pkgviews documentation?
9.3. Utilities for package management (pkgtools)
9.4. How to use pkgsrc as non-root
9.5. How to resume transfers when fetching distfiles?
9.6. How can I install/use modular X.org from pkgsrc?
9.7. How to fetch files from behind a firewall
9.8. How do I tell make fetch to do passive FTP?
9.9. How to fetch all distfiles at once
9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
9.11. What does "Could not find bsd.own.mk" mean?
9.12. Using 'sudo' with pkgsrc
9.13. How do I change the location of configuration files?
9.14. Automated security checks
9.15. Why do some packages ignore my CFLAGS?
9.16. A package does not build. What shall I do?
9.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
    conflicts" mean?

This section contains hints, tips & tricks on special things in pkgsrc that we
didn't find a better place for in the previous chapters, and it contains items
for both pkgsrc users and developers.

9.1. Are there any mailing lists for pkg-related discussion?

The following mailing lists may be of interest to pkgsrc users:

  * pkgsrc-users: This is a general purpose list for most issues regarding
    pkgsrc, regardless of platform, e.g. soliciting user help for pkgsrc
    configuration, unexpected build failures, using particular packages,
    upgrading pkgsrc installations, questions regarding the pkgsrc release
    branches, etc. General announcements or proposals for changes that impact
    the pkgsrc user community, e.g. major infrastructure changes, new features,
    package removals, etc., may also be posted.

  * pkgsrc-bulk: A list where the results of pkgsrc bulk builds are sent and
    discussed.

  * pkgsrc-changes: This list is for those who are interested in getting a
    commit message for every change committed to pkgsrc. It is also available
    in digest form, meaning one daily message containing all commit messages
    for changes to the package source tree in that 24 hour period.

To subscribe, do:

% echo subscribe listname | mail majordomo@NetBSD.org

Archives for all these mailing lists are available from http://
mail-index.NetBSD.org/.

9.2. Where's the pkgviews documentation?

Pkgviews is tightly integrated with buildlink. You can find a pkgviews User's
guide in pkgsrc/mk/buildlink3/PKGVIEWS_UG.

9.3. Utilities for package management (pkgtools)

The directory pkgsrc/pkgtools contains a number of useful utilities for both
users and developers of pkgsrc. This section attempts only to make the reader
aware of the utilities and when they might be useful, and not to duplicate the
documentation that comes with each package.

Utilities used by pkgsrc (automatically installed when needed):

  * pkgtools/x11-links: Symlinks for use by buildlink.

OS tool augmentation (automatically installed when needed):

  * pkgtools/digest: Calculates various kinds of checksums (including SHA1).

  * pkgtools/libnbcompat: Compatibility library for pkgsrc tools.

  * pkgtools/mtree: Installed on non-BSD systems due to lack of native mtree.

  * pkgtools/pkg_install: Up-to-date replacement for /usr/sbin/pkg_install, or
    for use on operating systems where pkg_install is not present.

Utilities used by pkgsrc (not automatically installed):

  * pkgtools/pkg_tarup: Create a binary package from an already-installed
    package. Used by make replace to save the old package.

  * pkgtools/dfdisk: Adds extra functionality to pkgsrc, allowing it to fetch
    distfiles from multiple locations. It currently supports the following
    methods: multiple CD-ROMs and network FTP/HTTP connections.

  * pkgtools/xpkgwedge: Put X11 packages someplace else (enabled by default).

  * devel/cpuflags: Determine the best compiler flags to optimise code for your
    current CPU and compiler.

Utilities for keeping track of installed packages, being up to date, etc:

  * pkgtools/pkg_chk: Reports on packages whose installed versions do not match
    the latest pkgsrc entries.

  * pkgtools/pkgdep: Makes dependency graphs of packages, to aid in choosing a
    strategy for updating.

  * pkgtools/pkgdepgraph: Makes graphs from the output of pkgtools/pkgdep (uses
    graphviz).

  * pkgtools/pkglint: The pkglint(1) program checks a pkgsrc entry for errors.

  * pkgtools/lintpkgsrc: The lintpkgsrc(1) program does various checks on the
    complete pkgsrc system.

  * pkgtools/pkgsurvey: Report what packages you have installed.

Utilities for people maintaining or creating individual packages:

  * pkgtools/pkgdiff: Automate making and maintaining patches for a package
    (includes pkgdiff, pkgvi, mkpatches, etc.).

  * pkgtools/rpm2pkg, pkgtools/url2pkg: Aids in converting to pkgsrc.

  * pkgtools/gensolpkg: Convert pkgsrc to a Solaris package.

Utilities for people maintaining pkgsrc (or: more obscure pkg utilities)

  * pkgtools/pkg_comp: Build packages in a chrooted area.

  * pkgtools/libkver: Spoof kernel version for chrooted cross builds.

9.4. How to use pkgsrc as non-root

If you want to use pkgsrc as non-root user, you can set some variables to make
pkgsrc work under these conditions. At the very least, you need to set
UNPRIVILEGED to "yes"; this will turn on unprivileged mode and set multiple
related variables to allow installation of packages as non-root.

In case the defaults are not enough, you may want to tune some other variables
used. For example, if the automatic user/group detection leads to incorrect
values (or not the ones you would like to use), you can change them by setting
UNPRIVILEGED_USER and UNPRIVILEGED_GROUP respectively.

As regards bootstrapping, please note that the bootstrap script will ease
non-root configuration when given the "--ignore-user-check" flag, as it will
choose and use multiple default directories under ~/pkg as the installation
targets. These directories can be overridden by the "--prefix" flag provided by
the script, as well as some others that allow finer tuning of the tree layout.

9.5. How to resume transfers when fetching distfiles?

By default, resuming transfers in pkgsrc is disabled, but you can enable this
feature by adding the option PKG_RESUME_TRANSFERS=YES into mk.conf. If, during
a fetch step, an incomplete distfile is found, pkgsrc will try to resume it.

You can also use a different program than the default ftp(1) by changing the
FETCH_USING variable. You can specify the program by using of ftp, fetch, wget
or curl. Alternatively, fetching can be disabled by using the value manual. A
value of custom disables the system defaults and dependency tracking for the
fetch program. In that case you have to provide FETCH_CMD, FETCH_BEFORE_ARGS,
FETCH_RESUME_ARGS, FETCH_OUTPUT_ARGS, FETCH_AFTER_ARGS.

For example, if you want to use wget to download, you'll have to use something
like:

FETCH_USING= wget

9.6. How can I install/use modular X.org from pkgsrc?

If you want to use modular X.org from pkgsrc instead of your system's own X11
(/usr/X11R6, /usr/openwin, ...) you will have to add the following line into
mk.conf:

X11_TYPE=modular

Note

The DragonFly operating system defaults to using modular X.org from pkgsrc.

9.7. How to fetch files from behind a firewall

If you are sitting behind a firewall which does not allow direct connections to
Internet hosts (i.e. non-NAT), you may specify the relevant proxy hosts. This
is done using an environment variable in the form of a URL, e.g. in Amdahl, the
machine "orpheus.amdahl.com" is one of the firewalls, and it uses port 80 as
the proxy port number. So the proxy environment variables are:

ftp_proxy=ftp://orpheus.amdahl.com:80/
http_proxy=http://orpheus.amdahl.com:80/

9.8. How do I tell make fetch to do passive FTP?

This depends on which utility is used to retrieve distfiles. From bsd.pkg.mk,
FETCH_CMD is assigned the first available command from the following list:

  * ${LOCALBASE}/bin/ftp

  * /usr/bin/ftp

On a default NetBSD installation, this will be /usr/bin/ftp, which
automatically tries passive connections first, and falls back to active
connections if the server refuses to do passive. For the other tools, add the
following to your mk.conf file: PASSIVE_FETCH=1.

Having that option present will prevent /usr/bin/ftp from falling back to
active transfers.

9.9. How to fetch all distfiles at once

You would like to download all the distfiles in a single batch from work or
university, where you can't run a make fetch. There is an archive of distfiles
on ftp.NetBSD.org, but downloading the entire directory may not be appropriate.

The answer here is to do a make fetch-list in /usr/pkgsrc or one of its
subdirectories, carry the resulting list to your machine at work/school and use
it there. If you don't have a NetBSD-compatible ftp(1) (like tnftp) at work,
don't forget to set FETCH_CMD to something that fetches a URL:

At home:

% cd /usr/pkgsrc
% make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles >/tmp/fetch.sh
% scp /tmp/fetch.sh work:/tmp

At work:

% sh /tmp/fetch.sh

then tar up /tmp/distfiles and take it home.

If you have a machine running NetBSD, and you want to get all distfiles (even
ones that aren't for your machine architecture), you can do so by using the
above-mentioned make fetch-list approach, or fetch the distfiles directly by
running:

% make mirror-distfiles

If you even decide to ignore NO_{SRC,BIN}_ON_{FTP,CDROM}, then you can get
everything by running:

% make fetch NO_SKIP=yes

9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?

When compiling the pkgtools/pkg_install package, you get the error from make
that it doesn't know how to make /usr/share/tmac/tmac.andoc? This indicates
that you don't have installed the "text" set (nroff, ...) from the NetBSD base
distribution on your machine. It is recommended to do that to format man pages.

In the case of the pkgtools/pkg_install package, you can get away with setting
NOMAN=YES either in the environment or in mk.conf.

9.11. What does "Could not find bsd.own.mk" mean?

You didn't install the compiler set, comp.tgz, when you installed your NetBSD
machine. Please get and install it, by extracting it in /:

# cd /
# tar --unlink -zxvpf .../comp.tgz

comp.tgz is part of every NetBSD release. Get the one that corresponds to your
release (determine via uname -r).

9.12. Using 'sudo' with pkgsrc

When installing packages as non-root user and using the just-in-time su(1)
feature of pkgsrc, it can become annoying to type in the root password for each
required package installed. To avoid this, the sudo package can be used, which
does password caching over a limited time. To use it, install sudo (either as
binary package or from security/sudo) and then put the following into your
mk.conf, somewhere after the definition of the LOCALBASE variable:

.if exists(${LOCALBASE}/bin/sudo)
SU_CMD= ${LOCALBASE}/bin/sudo /bin/sh -c
.endif

9.13. How do I change the location of configuration files?

As the system administrator, you can choose where configuration files are
installed. The default settings make all these files go into ${PREFIX}/etc or
some of its subdirectories; this may be suboptimal depending on your
expectations (e.g., a read-only, NFS-exported PREFIX with a need of per-machine
configuration of the provided packages).

In order to change the defaults, you can modify the PKG_SYSCONFBASE variable
(in mk.conf) to point to your preferred configuration directory; some common
examples include /etc or /etc/pkg.

Furthermore, you can change this value on a per-package basis by setting the
PKG_SYSCONFDIR.${PKG_SYSCONFVAR} variable. PKG_SYSCONFVAR's value usually
matches the name of the package you would like to modify, that is, the contents
of PKGBASE.

Note that after changing these settings, you must rebuild and reinstall any
affected packages.

9.14. Automated security checks

Please be aware that there can often be bugs in third-party software, and some
of these bugs can leave a machine vulnerable to exploitation by attackers. In
an effort to lessen the exposure, the NetBSD packages team maintains a database
of known-exploits to packages which have at one time been included in pkgsrc.
The database can be downloaded automatically, and a security audit of all
packages installed on a system can take place. To do this, refer to the
following two tools (installed as part of the pkgtools/pkg_install package):

 1. pkg_admin fetch-pkg-vulnerabilities, an easy way to download a list of the
    security vulnerabilities information. This list is kept up to date by the
    pkgsrc security team, and is distributed from the NetBSD ftp server:

    ftp://ftp.NetBSD.org/pkgsrc/distfiles/pkg-vulnerabilities

 2. pkg_admin audit, an easy way to audit the current machine, checking each
    known vulnerability. If a vulnerable package is installed, it will be shown
    by output to stdout, including a description of the type of vulnerability,
    and a URL containing more information.

Use of these tools is strongly recommended! After "pkg_install" is installed,
please read the package's message, which you can get by running pkg_info -D
pkg_install.

If this package is installed, pkgsrc builds will use it to perform a security
check before building any package. See Section 5.2, "Variables affecting the
build process" for ways to control this check.

9.15. Why do some packages ignore my CFLAGS?

When you add your own preferences to the CFLAGS variable in your mk.conf, these
flags are passed in environment variables to the ./configure scripts and to
make(1). Some package authors ignore the CFLAGS from the environment variable
by overriding them in the Makefiles of their package.

Currently there is no solution to this problem. If you really need the package
to use your CFLAGS you should run make patch in the package directory and then
inspect any Makefile and Makefile.in for whether they define CFLAGS explicitly.
Usually you can remove these lines. But be aware that some "smart" programmers
write so bad code that it only works for the specific combination of CFLAGS
they have chosen.

9.16. A package does not build. What shall I do?

 1. Make sure that your copy of pkgsrc is consistent. A case that occurs often
    is that people only update pkgsrc in parts, because of performance reasons.
    Since pkgsrc is one large system, not a collection of many small systems,
    there are sometimes changes that only work when the whole pkgsrc tree is
    updated.

 2. Make sure that you don't have any CVS conflicts. Search for "<<<<<<" or "
    >>>>>>" in all your pkgsrc files.

 3. Make sure that you don't have old copies of the packages extracted. Run
    make clean clean-depends to verify this.

 4. If the problem still exists, write a mail to the pkgsrc-users mailing list.

9.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
conflicts" mean?

You have modified a file from pkgsrc, and someone else has modified that same
file afterwards in the CVS repository. Both changes are in the same region of
the file, so when you updated pkgsrc, the cvs command marked the conflicting
changes in the file. Because of these markers, the file is no longer a valid
Makefile.

Have a look at that file, and if you don't need your local changes anymore, you
can remove that file and run cvs -q update -dP in that directory to download
the current version.

Part II. The pkgsrc developer's guide

This part of the book deals with creating and modifying packages. It starts
with a "HOWTO"-like guide on creating a new package. The remaining chapters are
more like a reference manual for pkgsrc.

Table of Contents

10. Creating a new pkgsrc package from scratch

    10.1. Common types of packages

        10.1.1. Perl modules
        10.1.2. KDE applications
        10.1.3. Python modules and programs

    10.2. Examples

        10.2.1. How the www/nvu package came into pkgsrc

11. Package components - files, directories and contents

    11.1. Makefile
    11.2. distinfo
    11.3. patches/*

        11.3.1. Structure of a single patch file
        11.3.2. Creating patch files
        11.3.3. Sources where the patch files come from
        11.3.4. Patching guidelines
        11.3.5. Feedback to the author

    11.4. Other mandatory files
    11.5. Optional files

        11.5.1. Files affecting the binary package
        11.5.2. Files affecting the build process
        11.5.3. Files affecting nothing at all

    11.6. work*
    11.7. files/*

12. Programming in Makefiles

    12.1. Caveats
    12.2. Makefile variables

        12.2.1. Naming conventions

    12.3. Code snippets

        12.3.1. Adding things to a list
        12.3.2. Converting an internal list into an external list
        12.3.3. Passing variables to a shell command
        12.3.4. Quoting guideline
        12.3.5. Workaround for a bug in BSD Make

13. PLIST issues

    13.1. RCS ID
    13.2. Semi-automatic PLIST generation
    13.3. Tweaking output of make print-PLIST
    13.4. Variable substitution in PLIST
    13.5. Man page compression
    13.6. Changing PLIST source with PLIST_SRC
    13.7. Platform-specific and differing PLISTs
    13.8. Sharing directories between packages

14. Buildlink methodology

    14.1. Converting packages to use buildlink3
    14.2. Writing buildlink3.mk files

        14.2.1. Anatomy of a buildlink3.mk file
        14.2.2. Updating BUILDLINK_API_DEPENDS.pkg and BUILDLINK_ABI_DEPENDS.
            pkg in buildlink3.mk files

    14.3. Writing builtin.mk files

        14.3.1. Anatomy of a builtin.mk file
        14.3.2. Global preferences for native or pkgsrc software

15. The pkginstall framework

    15.1. Files and directories outside the installation prefix

        15.1.1. Directory manipulation
        15.1.2. File manipulation

    15.2. Configuration files

        15.2.1. How PKG_SYSCONFDIR is set
        15.2.2. Telling the software where configuration files are
        15.2.3. Patching installations
        15.2.4. Disabling handling of configuration files

    15.3. System startup scripts

        15.3.1. Disabling handling of system startup scripts

    15.4. System users and groups
    15.5. System shells

        15.5.1. Disabling shell registration

    15.6. Fonts

        15.6.1. Disabling automatic update of the fonts databases

16. Options handling

    16.1. Global default options
    16.2. Converting packages to use bsd.options.mk
    16.3. Option Names
    16.4. Determining the options of dependencies

17. The build process

    17.1. Introduction
    17.2. Program location
    17.3. Directories used during the build process
    17.4. Running a phase
    17.5. The fetch phase

        17.5.1. What to fetch and where to get it from
        17.5.2. How are the files fetched?

    17.6. The checksum phase
    17.7. The extract phase
    17.8. The patch phase
    17.9. The tools phase
    17.10. The wrapper phase
    17.11. The configure phase
    17.12. The build phase
    17.13. The test phase
    17.14. The install phase
    17.15. The package phase
    17.16. Cleaning up
    17.17. Other helpful targets

18. Tools needed for building or running

    18.1. Tools for pkgsrc builds
    18.2. Tools needed by packages
    18.3. Tools provided by platforms
    18.4. Questions regarding the tools

19. Making your package work

    19.1. General operation

        19.1.1. Portability of packages
        19.1.2. How to pull in user-settable variables from mk.conf
        19.1.3. User interaction
        19.1.4. Handling licenses
        19.1.5. Restricted packages
        19.1.6. Handling dependencies
        19.1.7. Handling conflicts with other packages
        19.1.8. Packages that cannot or should not be built
        19.1.9. Packages which should not be deleted, once installed
        19.1.10. Handling packages with security problems
        19.1.11. How to handle incrementing versions when fixing an existing
            package
        19.1.12. Substituting variable text in the package files (the SUBST
            framework)

    19.2. Fixing problems in the fetch phase

        19.2.1. Packages whose distfiles aren't available for plain downloading
        19.2.2. How to handle modified distfiles with the 'old' name

    19.3. Fixing problems in the configure phase

        19.3.1. Shared libraries - libtool
        19.3.2. Using libtool on GNU packages that already support libtool
        19.3.3. GNU Autoconf/Automake

    19.4. Programming languages

        19.4.1. C, C++, and Fortran
        19.4.2. Java
        19.4.3. Packages containing perl scripts
        19.4.4. Other programming languages

    19.5. Fixing problems in the build phase

        19.5.1. Compiling C and C++ code conditionally
        19.5.2. How to handle compiler bugs
        19.5.3. Undefined reference to "..."
        19.5.4. Running out of memory

    19.6. Fixing problems in the install phase

        19.6.1. Creating needed directories
        19.6.2. Where to install documentation
        19.6.3. Installing highscore files
        19.6.4. Adding DESTDIR support to packages
        19.6.5. Packages with hardcoded paths to other interpreters
        19.6.6. Packages installing perl modules
        19.6.7. Packages installing info files
        19.6.8. Packages installing man pages
        19.6.9. Packages installing GConf data files
        19.6.10. Packages installing scrollkeeper/rarian data files
        19.6.11. Packages installing X11 fonts
        19.6.12. Packages installing GTK2 modules
        19.6.13. Packages installing SGML or XML data
        19.6.14. Packages installing extensions to the MIME database
        19.6.15. Packages using intltool
        19.6.16. Packages installing startup scripts
        19.6.17. Packages installing TeX modules
        19.6.18. Packages supporting running binaries in emulation
        19.6.19. Packages installing hicolor theme icons
        19.6.20. Packages installing desktop files

    19.7. Marking packages as having problems

20. Debugging
21. Submitting and Committing

    21.1. Submitting binary packages
    21.2. Submitting source packages (for non-NetBSD-developers)
    21.3. General notes when adding, updating, or removing packages
    21.4. Committing: Adding a package to CVS
    21.5. Updating a package to a newer version
    21.6. Renaming a package in pkgsrc
    21.7. Moving a package in pkgsrc

22. Frequently Asked Questions
23. GNOME packaging and porting

    23.1. Meta packages
    23.2. Packaging a GNOME application
    23.3. Updating GNOME to a newer version
    23.4. Patching guidelines

Chapter 10. Creating a new pkgsrc package from scratch

Table of Contents

10.1. Common types of packages

    10.1.1. Perl modules
    10.1.2. KDE applications
    10.1.3. Python modules and programs

10.2. Examples

    10.2.1. How the www/nvu package came into pkgsrc

When you find a package that is not yet in pkgsrc, you most likely have a URL
from where you can download the source code. Starting with this URL, creating a
package involves only a few steps.

 1. First, install the packages pkgtools/url2pkg and pkgtools/pkglint.

 2. Then, choose one of the top-level directories as the category in which you
    want to place your package. You can also create a directory of your own
    (maybe called local). In that category directory, create another directory
    for your package and change into it.

 3. Run the program url2pkg, which will ask you for a URL. Enter the URL of the
    distribution file (in most cases a .tar.gz file) and watch how the basic
    ingredients of your package are created automatically. The distribution
    file is extracted automatically to fill in some details in the Makefile
    that would otherwise have to be done manually.

 4. Examine the extracted files to determine the dependencies of your package.
    Ideally, this is mentioned in some README file, but things may differ. For
    each of these dependencies, look where it exists in pkgsrc, and if there is
    a file called buildlink3.mk in that directory, add a line to your package
    Makefile which includes that file just before the last line. If the
    buildlink3.mk file does not exist, it must be created first. The
    buildlink3.mk file makes sure that the package's include files and
    libraries are provided.

    If you just need binaries from a package, add a DEPENDS line to the
    Makefile, which specifies the version of the dependency and where it can be
    found in pkgsrc. This line should be placed in the third paragraph. If the
    dependency is only needed for building the package, but not when using it,
    use BUILD_DEPENDS instead of DEPENDS. Your package may then look like this:

    [...]

    BUILD_DEPENDS+= lua>=5.0:../../lang/lua
    DEPENDS+= screen-[0-9]*:../../misc/screen
    DEPENDS+= screen>=4.0:../../misc/screen

    [...]

    .include "../../category/package/buildlink3.mk"
    .include "../../devel/glib2/buildlink3.mk"
    .include "../../mk/bsd.pkg.mk"

 5. Run pkglint to see what things still need to be done to make your package a
    "good" one. If you don't know what pkglint's warnings want to tell you, try
    pkglint --explain or pkglint -e, which outputs additional explanations.

 6. In many cases the package is not yet ready to build. You can find
    instructions for the most common cases in the next section, Section 10.1,
    "Common types of packages". After you have followed the instructions over
    there, you can hopefully continue here.

 7. Run bmake clean to clean the working directory from the extracted files.
    Besides these files, a lot of cache files and other system information has
    been saved in the working directory, which may become wrong after you
    edited the Makefile.

 8. Now, run bmake to build the package. For the various things that can go
    wrong in this phase, consult Chapter 19, Making your package work.

 9. When the package builds fine, the next step is to install the package. Run
    bmake install and hope that everything works.

10. Up to now, the file PLIST, which contains a list of the files that are
    installed by the package, is nearly empty. Run bmake print-PLIST >PLIST to
    generate a probably correct list. Check the file using your preferred text
    editor to see if the list of files looks plausible.

11. Run pkglint again to see if the generated PLIST contains garbage or not.

12. When you ran bmake install, the package has been registered in the database
    of installed files, but with an empty list of files. To fix this, run bmake
    deinstall and bmake install again. Now the package is registered with the
    list of files from PLIST.

13. Run bmake package to create a binary package from the set of installed
    files.

10.1. Common types of packages

10.1.1. Perl modules

Simple Perl modules are handled automatically by url2pkg, including
dependencies.

10.1.2. KDE applications

KDE applications should always include meta-pkgs/kde3/kde3.mk, which contains
numerous settings that are typical of KDE packages.

10.1.3. Python modules and programs

Python modules and programs packages are easily created using a set of
predefined variables.

Most Python packages use either "distutils" or easy-setup ("eggs"). If the
software uses "distutils", set the PYDISTUTILSPKG variable to "yes" so pkgsrc
will make use of this framework. "distutils" uses a script called setup.py, if
the "distutils" driver is not called setup.py, set the PYSETUP variable to the
name of the script.

If the default Python versions are not supported by the software, set the
PYTHON_VERSIONS_ACCEPTED variable to the Python versions the software is known
to work with, from the most recent to the older one, e.g.

PYTHON_VERSIONS_ACCEPTED= 31 27 26

If the packaged software is a Python module, include "../../lang/python/
extension.mk". In this case, the package directory should be called "
py-software" and PKGNAME should be set to "${PYPKGPREFIX}-${DISTNAME}", e.g.

DISTNAME= foopymodule-1.2.10
PKGNAME= ${PYPKGPREFIX}-${DISTNAME}

If it is an application, also include "../../lang/python/application.mk" before
"extension.mk".

If the packaged software, either it is an application or a module, is
egg-aware, you only need to include "../../lang/python/egg.mk".

In order to correctly set the path to the Python interpreter, use the
REPLACE_PYTHON variable and set it to the list of files (paths relative to
WRKSRC) that must be corrected. For example :

REPLACE_PYTHON= *.py

10.2. Examples

10.2.1. How the www/nvu package came into pkgsrc

10.2.1.1. The initial package

Looking at the file pkgsrc/doc/TODO, I saw that the "nvu" package has not yet
been imported into pkgsrc. As the description says it has to do with the web,
the obvious choice for the category is "www".

$ mkdir www/nvu
$ cd www/nvu

The web site says that the sources are available as a tar file, so I fed that
URL to the url2pkg program:

$ url2pkg http://cvs.nvu.com/download/nvu-1.0-sources.tar.bz2

My editor popped up, and I added a PKGNAME line below the DISTNAME line, as the
package name should not have the word "sources" in it. I also filled in the
MAINTAINER, HOMEPAGE and COMMENT fields. Then the package Makefile looked like
that:

# $NetBSD$
#

DISTNAME= nvu-1.0-sources
PKGNAME= nvu-1.0
CATEGORIES= www
MASTER_SITES= http://cvs.nvu.com/download/
EXTRACT_SUFX= .tar.bz2

MAINTAINER= rillig@NetBSD.org
HOMEPAGE= http://cvs.nvu.com/
COMMENT= Web Authoring System

# url2pkg-marker (please do not remove this line.)
.include "../../mk/bsd.pkg.mk"

Then, I quit the editor and watched pkgsrc downloading a large source archive:

url2pkg> Running "make makesum" ...
=> Required installed package digest>=20010302: digest-20060826 found
=> Fetching nvu-1.0-sources.tar.bz2
Requesting http://cvs.nvu.com/download/nvu-1.0-sources.tar.bz2
100% |*************************************| 28992 KB 150.77 KB/s00:00 ETA
29687976 bytes retrieved in 03:12 (150.77 KB/s)
url2pkg> Running "make extract" ...
=> Required installed package digest>=20010302: digest-20060826 found
=> Checksum SHA1 OK for nvu-1.0-sources.tar.bz2
=> Checksum RMD160 OK for nvu-1.0-sources.tar.bz2
work.bacc -> /tmp/roland/pkgsrc/www/nvu/work.bacc
===> Installing dependencies for nvu-1.0
===> Overriding tools for nvu-1.0
===> Extracting for nvu-1.0
url2pkg> Adjusting the Makefile.

Remember to correct CATEGORIES, HOMEPAGE, COMMENT, and DESCR when you're done!

Good luck! (See pkgsrc/doc/pkgsrc.txt for some more help :-)

10.2.1.2. Fixing all kinds of problems to make the package work

Now that the package has been extracted, let's see what's inside it. The
package has a README.txt, but that only says something about mozilla, so it's
probably useless for seeing what dependencies this package has. But since there
is a GNU configure script in the package, let's hope that it will complain
about everything it needs.

$ bmake
=> Required installed package digest>=20010302: digest-20060826 found
=> Checksum SHA1 OK for nvu-1.0-sources.tar.bz2
=> Checksum RMD160 OK for nvu-1.0-sources.tar.bz2
===> Patching for nvu-1.0
===> Creating toolchain wrappers for nvu-1.0
===> Configuring for nvu-1.0
[...]
configure: error: Perl 5.004 or higher is required.
[...]
WARNING: Please add USE_TOOLS+=perl to the package Makefile.
[...]

That worked quite well. So I opened the package Makefile in my editor, and
since it already has a USE_TOOLS line, I just appended "perl" to it. Since the
dependencies of the package have changed now, and since a perl wrapper is
automatically installed in the "tools" phase, I need to build the package from
scratch.

$ bmake clean
===> Cleaning for nvu-1.0
$ bmake
[...]
*** /tmp/roland/pkgsrc/www/nvu/work.bacc/.tools/bin/make is not \
GNU Make. You will not be able to build Mozilla without GNU Make.
[...]

So I added "gmake" to the USE_TOOLS line and tried again (from scratch).

[...]
checking for GTK - version >= 1.2.0... no
*** Could not run GTK test program, checking why...
[...]

Now to the other dependencies. The first question is: Where is the GTK package
hidden in pkgsrc?

$ echo ../../*/gtk*
[many packages ...]
$ echo ../../*/gtk
../../x11/gtk
$ echo ../../*/gtk2
../../x11/gtk2
$ echo ../../*/gtk2/bui*
../../x11/gtk2/buildlink3.mk

The first try was definitely too broad. The second one had exactly one result,
which is very good. But there is one pitfall with GNOME packages. Before GNOME
2 had been released, there were already many GNOME 1 packages in pkgsrc. To be
able to continue to use these packages, the GNOME 2 packages were imported as
separate packages, and their names usually have a "2" appended. So I checked
whether this was the case here, and indeed it was.

Since the GTK2 package has a buildlink3.mk file, adding the dependency is very
easy. I just inserted an .include line before the last line of the package
Makefile, so that it now looks like this:

[...]
.include "../../x11/gtk2/buildlink3.mk"
.include "../../mk/bsd.pkg.mk

After another bmake clean && bmake, the answer was:

[...]
checking for gtk-config... /home/roland/pkg/bin/gtk-config
checking for GTK - version >= 1.2.0... no
*** Could not run GTK test program, checking why...
*** The test program failed to compile or link. See the file config.log for the
*** exact error that occured. This usually means GTK was incorrectly installed
*** or that you have moved GTK since it was installed. In the latter case, you
*** may want to edit the gtk-config script: /home/roland/pkg/bin/gtk-config
configure: error: Test for GTK failed.
[...]

In this particular case, the assumption that "every package prefers GNOME 2"
had been wrong. The first of the lines above told me that this package really
wanted to have the GNOME 1 version of GTK. If the package had looked for GTK2,
it would have looked for pkg-config instead of gtk-config. So I changed the x11
/gtk2 to x11/gtk in the package Makefile, and tried again.

[...]
cc -o xpidl.o -c -DOSTYPE=\"NetBSD3\" -DOSARCH=\"NetBSD\" -I../../../dist/include/xpcom -I../../../dist/include -I/tmp/roland/pkgsrc/www/nvu/work.bacc/mozilla/dist/include/nspr -I/usr/X11R6/include -fPIC -DPIC -I/home/roland/pkg/include -I/usr/include -I/usr/X11R6/include -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -pedantic -O2 -I/home/roland/pkg/include -I/usr/include -Dunix -pthread -pipe -DDEBUG -D_DEBUG -DDEBUG_roland -DTRACING -g -I/home/roland/pkg/include/glib/glib-1.2 -I/home/roland/pkg/lib/glib/include -I/usr/pkg/include/orbit-1.0 -I/home/roland/pkg/include -I/usr/include -I/usr/X11R6/include -include ../../../mozilla-config.h -DMOZILLA_CLIENT -Wp,-MD,.deps/xpidl.pp xpidl.c
In file included from xpidl.c:42:
xpidl.h:53:24: libIDL/IDL.h: No such file or directory
In file included from xpidl.c:42:
xpidl.h:132: error: parse error before "IDL_ns"
[...]

The package still does not find all of its dependencies. Now the question is:
Which package provides the libIDL/IDL.h header file?

$ echo ../../*/*idl*
../../devel/py-idle ../../wip/idled ../../x11/acidlaunch
$ echo ../../*/*IDL*
../../net/libIDL

Let's take the one from the second try. So I included the ../../net/libIDL/
buildlink3.mk file and tried again. But the error didn't change. After digging
through some of the code, I concluded that the build process of the package was
broken and couldn't have ever worked, but since the Mozilla source tree is
quite large, I didn't want to fix it. So I added the following to the package
Makefile and tried again:

CPPFLAGS+= -I${BUILDLINK_PREFIX.libIDL}/include/libIDL-2.0
BUILDLINK_TRANSFORM+= -l:IDL:IDL-2

The latter line is needed because the package expects the library libIDL.so,
but only libIDL-2.so is available. So I told the compiler wrapper to rewrite
that on the fly.

The next problem was related to a recent change of the FreeType interface. I
looked up in www/seamonkey which patch files were relevant for this issue and
copied them to the patches directory. Then I retried, fixed the patches so that
they applied cleanly and retried again. This time, everything worked.

10.2.1.3. Installing the package

$ bmake CHECK_FILES=no install
[...]
$ bmake print-PLIST >PLIST
$ bmake deinstall
$ bmake install

Chapter 11. Package components - files, directories and contents

Table of Contents

11.1. Makefile
11.2. distinfo
11.3. patches/*

    11.3.1. Structure of a single patch file
    11.3.2. Creating patch files
    11.3.3. Sources where the patch files come from
    11.3.4. Patching guidelines
    11.3.5. Feedback to the author

11.4. Other mandatory files
11.5. Optional files

    11.5.1. Files affecting the binary package
    11.5.2. Files affecting the build process
    11.5.3. Files affecting nothing at all

11.6. work*
11.7. files/*

Whenever you're preparing a package, there are a number of files involved which
are described in the following sections.

11.1. Makefile

Building, installation and creation of a binary package are all controlled by
the package's Makefile. The Makefile describes various things about a package,
for example from where to get it, how to configure, build, and install it.

A package Makefile contains several sections that describe the package.

In the first section there are the following variables, which should appear
exactly in the order given here. The order and grouping of the variables is
mostly historical and has no further meaning.

  * DISTNAME is the basename of the distribution file to be downloaded from the
    package's website.

  * PKGNAME is the name of the package, as used by pkgsrc. You only need to
    provide it if DISTNAME (which is the default) is not a good name for the
    package in pkgsrc. Usually it is the pkgsrc directory name together with
    the version number. It must match the regular expression ^[A-Za-z0-9]
    [A-Za-z0-9-_.+]*$, that is, it starts with a letter or digit, and contains
    only letters, digits, dashes, underscores, dots and plus signs.

  * SVR4_PKGNAME is the name of the package file to create if the PKGNAME isn't
    unique on a SVR4 system. The default is PKGNAME, which may be shortened
    when you use pkgtools/gensolpkg. Only add SVR4_PKGNAME if PKGNAME does not
    produce an unique package name on a SVR4 system. The length of SVR4_PKGNAME
    is limited to 5 characters.

  * CATEGORIES is a list of categories which the package fits in. You can
    choose any of the top-level directories of pkgsrc for it.

    Currently the following values are available for CATEGORIES. If more than
    one is used, they need to be separated by spaces:

    archivers cross geography meta-pkgs security
    audio databases graphics misc shells
    benchmarks devel ham multimedia sysutils
    biology editors inputmethod net textproc
    cad emulators lang news time
    chat finance mail parallel wm
    comms fonts math pkgtools www
    converters games mbone print x11

  * MASTER_SITES, DYNAMIC_MASTER_SITES, DIST_SUBDIR, EXTRACT_SUFX and DISTFILES
    are discussed in detail in Section 17.5, "The fetch phase".

The second section contains information about separately downloaded patches, if
any.

  * PATCHFILES: Name(s) of additional files that contain distribution patches.
    There is no default. pkgsrc will look for them at PATCH_SITES. They will
    automatically be uncompressed before patching if the names end with .gz or
    .Z.

  * PATCH_SITES: Primary location(s) for distribution patch files (see
    PATCHFILES below) if not found locally.

The third section contains the following variables.

  * MAINTAINER is the email address of the person who feels responsible for
    this package, and who is most likely to look at problems or questions
    regarding this package which have been reported with send-pr(1). Other
    developers may contact the MAINTAINER before making changes to the package,
    but are not required to do so. When packaging a new program, set MAINTAINER
    to yourself. If you really can't maintain the package for future updates,
    set it to <pkgsrc-users@NetBSD.org>.

  * OWNER should be used instead of MAINTAINER when you do not want other
    developers to update or change the package without contacting you first. A
    package Makefile should contain one of MAINTAINER or OWNER, but not both.

  * HOMEPAGE is a URL where users can find more information about the package.

  * COMMENT is a one-line description of the package (should not include the
    package name).

Other variables that affect the build:

  * WRKSRC: The directory where the interesting distribution files of the
    package are found. The default is ${WRKDIR}/${DISTNAME}, which works for
    most packages.

    If a package doesn't create a subdirectory for itself (most GNU software
    does, for instance), but extracts itself in the current directory, you
    should set WRKSRC=${WRKDIR}.

    If a package doesn't create a subdirectory with the name of DISTNAME but
    some different name, set WRKSRC to point to the proper name in ${WRKDIR},
    for example WRKSRC=${WRKDIR}/${DISTNAME}/unix. See lang/tcl and x11/tk for
    other examples.

    The name of the working directory created by pkgsrc is taken from the
    WRKDIR_BASENAME variable. By default, its value is work. If you want to use
    the same pkgsrc tree for building different kinds of binary packages, you
    can change the variable according to your needs. Two other variables handle
    common cases of setting WRKDIR_BASENAME individually. If OBJHOSTNAME is
    defined in mk.conf, the first component of the host's name is attached to
    the directory name. If OBJMACHINE is defined, the platform name is
    attached, which might look like work.i386 or work.sparc.

Please pay attention to the following gotchas:

  * Add MANCOMPRESSED if man pages are installed in compressed form by the
    package. For packages using BSD-style makefiles which honor MANZ, there is
    MANCOMPRESSED_IF_MANZ.

  * Replace /usr/local with "${PREFIX}" in all files (see patches, below).

  * If the package installs any info files, see Section 19.6.7, "Packages
    installing info files".

11.2. distinfo

The distinfo file contains the message digest, or checksum, of each distfile
needed for the package. This ensures that the distfiles retrieved from the
Internet have not been corrupted during transfer or altered by a malign force
to introduce a security hole. Due to recent rumor about weaknesses of digest
algorithms, all distfiles are protected using both SHA1 and RMD160 message
digests, as well as the file size.

The distinfo file also contains the checksums for all the patches found in the
patches directory (see Section 11.3, "patches/*").

To regenerate the distinfo file, use the make makedistinfo or make mdi command.

Some packages have different sets of distfiles depending on the platform, for
example lang/openjdk7. These are kept in the same distinfo file and care should
be taken when upgrading such a package to ensure distfile information is not
lost.

11.3. patches/*

Many packages still don't work out-of-the box on the various platforms that are
supported by pkgsrc. Therefore, a number of custom patch files are needed to
make the package work. These patch files are found in the patches/ directory.

In the patch phase, these patches are applied to the files in WRKSRC directory
after extracting them, in alphabetic order.

11.3.1. Structure of a single patch file

The patch-* files should be in diff -bu format, and apply without a fuzz to
avoid problems. (To force patches to apply with fuzz you can set
PATCH_FUZZ_FACTOR=-F2). Furthermore, each patch should contain only changes for
a single file, and no file should be patched by more than one patch file. This
helps to keep future modifications simple.

Each patch file is structured as follows: In the first line, there is the RCS
Id of the patch itself. The second line should be empty for aesthetic reasons.
After that, there should be a comment for each change that the patch does.
There are a number of standard cases:

  * Patches for commonly known vulnerabilities should mention the vulnerability
    ID (CAN, CVE).

  * Patches that change source code should mention the platform and other
    environment (for example, the compiler) that the patch is needed for.

In all, the patch should be commented so that any developer who knows the code
of the application can make some use of the patch. Special care should be taken
for the upstream developers, since we generally want that they accept our
patches, so we have less work in the future.

11.3.2. Creating patch files

One important thing to mention is to pay attention that no RCS IDs get stored
in the patch files, as these will cause problems when later checked into the
NetBSD CVS tree. Use the pkgdiff command from the pkgtools/pkgdiff package to
avoid these problems.

For even more automation, we recommend using mkpatches from the same package to
make a whole set of patches. You just have to backup files before you edit them
to filename.orig, e.g. with cp -p filename filename.orig or, easier, by using
pkgvi again from the same package. If you upgrade a package this way, you can
easily compare the new set of patches with the previously existing one with
patchdiff. The files in patches are replaced by new files, so carefully check
if you want to take all the changes.

When you have finished a package, remember to generate the checksums for the
patch files by using the make makepatchsum command, see Section 11.2,
"distinfo".

When adding a patch that corrects a problem in the distfile (rather than e.g.
enforcing pkgsrc's view of where man pages should go), send the patch as a bug
report to the maintainer. This benefits non-pkgsrc users of the package, and
usually makes it possible to remove the patch in future version.

The file names of the patch files are usually of the form patch-
path_to_file__with__underscores.c. Many packages still use the previous
convention patch-[a-z][a-z], but new patches should be of the form containing
the filename. mkpatches included in pkgtools/pkgdiff takes care of the name
automatically.

11.3.3. Sources where the patch files come from

If you want to share patches between multiple packages in pkgsrc, e.g. because
they use the same distfiles, set PATCHDIR to the path where the patch files can
be found, e.g.:

PATCHDIR= ${.CURDIR}/../xemacs/patches

Patch files that are distributed by the author or other maintainers can be
listed in PATCHFILES.

If it is desired to store any patches that should not be committed into pkgsrc,
they can be kept outside the pkgsrc tree in the $LOCALPATCHES directory. The
directory tree there is expected to have the same "category/package" structure
as pkgsrc, and patches are expected to be stored inside these dirs (also known
as $LOCALPATCHES/$PKGPATH). For example, if you want to keep a private patch
for pkgsrc/graphics/png, keep it in $LOCALPATCHES/graphics/png/mypatch. All
files in the named directory are expected to be patch files, and they are
applied after pkgsrc patches are applied.

11.3.4. Patching guidelines

When fixing a portability issue in the code do not use preprocessor magic to
check for the current operating system nor platform. Doing so hurts portability
to other platforms because the OS-specific details are not abstracted
appropriately.

The general rule to follow is: instead of checking for the operating system the
application is being built on, check for the specific features you need. For
example, instead of assuming that kqueue is available under NetBSD and using
the __NetBSD__ macro to conditionalize kqueue support, add a check that detects
kqueue itself ? yes, this generally involves patching the configure script.
There is absolutely nothing that prevents some OSes from adopting interfaces
from other OSes (e.g. Linux implementing kqueue), something that the above
checks cannot take into account.

Of course, checking for features generally involves more work on the
developer's side, but the resulting changes are cleaner and there are chances
they will work on many other platforms. Not to mention that there are higher
chances of being later integrated into the mainstream sources. Remember: It
doesn't work unless it is right!

Some typical examples:

Table 11.1. Patching examples

+-------------------------------------------------------------------------------------------+
| Where | Incorrect | Correct |
|---------+--------------------------+------------------------------------------------------|
| |case ${target_os} in | |
|configure|netbsd*) have_kvm=yes ;; |AC_CHECK_LIB(kvm, kvm_open, have_kvm=yes, have_kvm=no)|
|script |*) have_kvm=no ;; | |
| |esac | |
|---------+--------------------------+------------------------------------------------------|
|C source |#if defined(__NetBSD__) |#if defined(HAVE_SYS_EVENT_H) |
|file |# include <sys/event.h> |# include <sys/event.h> |
| |#endif |#endif |
|---------+--------------------------+------------------------------------------------------|
| |int |int |
| |monitor_file(...) |monitor_file(...) |
| |{ |{ |
| |#if defined(__NetBSD__) |#if defined(HAVE_KQUEUE) |
|C source | int fd = kqueue();| int fd = kqueue(); |
|file | ... | ... |
| |#else |#else |
| | ... | ... |
| |#endif |#endif |
| |} |} |
+-------------------------------------------------------------------------------------------+


For more information, please read the Making packager-friendly software article
(part 1, part 2). It summarizes multiple details on how to make software easier
to package; all the suggestions in it were collected from our experience in
pkgsrc work, so they are possibly helpful when creating patches too.

11.3.5. Feedback to the author

Always, always, always feed back any portability fixes or improvements you do
to a package to the mainstream developers. This is the only way to get their
attention on portability issues and to ensure that future versions can be built
out-of-the box on NetBSD. Furthermore, any user that gets newer distfiles will
get the fixes straight from the packaged code.

This generally involves cleaning up the patches (because sometimes the patches
that are added to pkgsrc are quick hacks), filling bug reports in the
appropriate trackers for the projects and working with the mainstream authors
to accept your changes. It is extremely important that you do it so that the
packages in pkgsrc are kept simple and thus further changes can be done without
much hassle.

When you have done this, please add a URL to the upstream bug report to the
patch comment.

Support the idea of free software!

11.4. Other mandatory files

DESCR

    A multi-line description of the piece of software. This should include any
    credits where they are due. Please bear in mind that others do not share
    your sense of humour (or spelling idiosyncrasies), and that others will
    read everything that you write here.

PLIST

    This file governs the files that are installed on your system: all the
    binaries, manual pages, etc. There are other directives which may be
    entered in this file, to control the creation and deletion of directories,
    and the location of inserted files. See Chapter 13, PLIST issues for more
    information.

11.5. Optional files

11.5.1. Files affecting the binary package

INSTALL

    This shell script is invoked twice by pkg_add(1). First time after package
    extraction and before files are moved in place, the second time after the
    files to install are moved in place. This can be used to do any custom
    procedures not possible with @exec commands in PLIST. See pkg_add(1) and
    pkg_create(1) for more information. See also Section 15.1, "Files and
    directories outside the installation prefix". Please note that you can
    modify variables in it easily by using FILES_SUBST in the package's
    Makefile:

    FILES_SUBST+= SOMEVAR="somevalue"

    replaces "@SOMEVAR@" with "somevalue" in the INSTALL. By default,
    substitution is performed for PREFIX, LOCALBASE, X11BASE, VARBASE, and a
    few others, type make help topic=FILES_SUBST for a complete list.

DEINSTALL

    This script is executed before and after any files are removed. It is this
    script's responsibility to clean up any additional messy details around the
    package's installation, since all pkg_delete knows is how to delete the
    files created in the original distribution. See pkg_delete(1) and
    pkg_create(1) for more information. The same methods to replace variables
    can be used as for the INSTALL file.

MESSAGE

    This file is displayed after installation of the package. Useful for things
    like legal notices on almost-free software and hints for updating config
    files after installing modules for apache, PHP etc. Please note that you
    can modify variables in it easily by using MESSAGE_SUBST in the package's
    Makefile:

    MESSAGE_SUBST+= SOMEVAR="somevalue"

    replaces "${SOMEVAR}" with "somevalue" in MESSAGE. By default, substitution
    is performed for PKGNAME, PKGBASE, PREFIX, LOCALBASE, X11PREFIX, X11BASE,
    PKG_SYSCONFDIR, ROOT_GROUP, and ROOT_USER.

    You can display a different or additional files by setting the MESSAGE_SRC
    variable. Its default is MESSAGE, if the file exists.

ALTERNATIVES

    FIXME: There is no documentation on the alternatives framework.

11.5.2. Files affecting the build process

Makefile.common

    This file contains arbitrary things that could also go into a Makefile, but
    its purpose is to be used by more than one package. This file should only
    be used when the packages that will use the file are known in advance. For
    other purposes it is often better to write a *.mk file and give it a good
    name that describes what it does.

buildlink3.mk

    This file contains the dependency information for the buildlink3 framework
    (see Chapter 14, Buildlink methodology).

hacks.mk

    This file contains workarounds for compiler bugs and similar things. It is
    included automatically by the pkgsrc infrastructure, so you don't need an
    extra .include line for it.

options.mk

    This file contains the code for the package-specific options (see
    Chapter 16, Options handling) that can be selected by the user. If a
    package has only one or two options, it is equally acceptable to put the
    code directly into the Makefile.

11.5.3. Files affecting nothing at all

README*

    These files do not take place in the creation of a package and thus are
    purely informative to the package developer.

TODO

    This file contains things that need to be done to make the package even
    better.

11.6. work*

When you type make, the distribution files are unpacked into the directory
denoted by WRKDIR. It can be removed by running make clean. Besides the
sources, this directory is also used to keep various timestamp files. The
directory gets removed completely on clean. The default is ${.CURDIR}/work or $
{.CURDIR}/work.${MACHINE_ARCH} if OBJMACHINE is set.

11.7. files/*

If you have any files that you wish to be placed in the package prior to
configuration or building, you could place these files here and use a ${CP}
command in the "pre-configure" target to achieve this. Alternatively, you could
simply diff the file against /dev/null and use the patch mechanism to manage
the creation of this file.

If you want to share files in this way with other packages, set the FILESDIR
variable to point to the other package's files directory, e.g.:

FILESDIR=${.CURDIR}/../xemacs/files

Chapter 12. Programming in Makefiles

Table of Contents

12.1. Caveats
12.2. Makefile variables

    12.2.1. Naming conventions

12.3. Code snippets

    12.3.1. Adding things to a list
    12.3.2. Converting an internal list into an external list
    12.3.3. Passing variables to a shell command
    12.3.4. Quoting guideline
    12.3.5. Workaround for a bug in BSD Make

Pkgsrc consists of many Makefile fragments, each of which forms a well-defined
part of the pkgsrc system. Using the make(1) system as a programming language
for a big system like pkgsrc requires some discipline to keep the code correct
and understandable.

The basic ingredients for Makefile programming are variables (which are
actually macros) and shell commands. Among these shell commands may even be
more complex ones like awk(1) programs. To make sure that every shell command
runs as intended it is necessary to quote all variables correctly when they are
used.

This chapter describes some patterns, that appear quite often in Makefiles,
including the pitfalls that come along with them.

12.1. Caveats

  * When you are creating a file as a target of a rule, always write the data
    to a temporary file first and finally rename that file. Otherwise there
    might occur an error in the middle of generating the file, and when the
    user runs make(1) for the second time, the file exists and will not be
    regenerated properly. Example:

    wrong:
            @echo "line 1" > ${.TARGET}
            @echo "line 2" >> ${.TARGET}
            @false

    correct:
            @echo "line 1" > ${.TARGET}.tmp
            @echo "line 2" >> ${.TARGET}.tmp
            @false
            @mv ${.TARGET}.tmp ${.TARGET}

    When you run make wrong twice, the file wrong will exist, although there
    was an error message in the first run. On the other hand, running make
    correct gives an error message twice, as expected.

    You might remember that make(1) sometimes removes ${.TARGET} in case of
    error, but this only happens when it is interrupted, for example by
    pressing ^C. This does not happen when one of the commands fails (like
    false(1) above).

12.2. Makefile variables

Makefile variables contain strings that can be processed using the five
operators ``='', ``+='', ``?='', ``:='', and ``!='', which are described in the
make(1) man page.

When a variable's value is parsed from a Makefile, the hash character ``#'' and
the backslash character ``\'' are handled specially. If a backslash is followed
by a newline, any whitespace immediately in front of the backslash, the
backslash, the newline, and any whitespace immediately behind the newline are
replaced with a single space. A backslash character and an immediately
following hash character are replaced with a single hash character. Otherwise,
the backslash is passed as is. In a variable assignment, any hash character
that is not preceded by a backslash starts a comment that continues upto the
end of the logical line.

Note: Because of this parsing algorithm the only way to create a variable
consisting of a single backslash is using the ``!='' operator, for example:
BACKSLASH!=echo "\\".

So far for defining variables. The other thing you can do with variables is
evaluating them. A variable is evaluated when it is part of the right side of
the ``:='' or the ``!='' operator, or directly before executing a shell command
which the variable is part of. In all other cases, make(1) performs lazy
evaluation, that is, variables are not evaluated until there's no other way.
The ``modifiers'' mentioned in the man page also evaluate the variable.

Some of the modifiers split the string into words and then operate on the
words, others operate on the string as a whole. When a string is split into
words, it is split as you would expect it from sh(1).

No rule without exception?the .for loop does not follow the shell quoting rules
but splits at sequences of whitespace.

There are several types of variables that should be handled differently.
Strings and two types of lists.

  * Strings can contain arbitrary characters. Nevertheless, you should restrict
    yourself to only using printable characters. Examples are PREFIX and
    COMMENT.

  * Internal lists are lists that are never exported to any shell command.
    Their elements are separated by whitespace. Therefore, the elements
    themselves cannot have embedded whitespace. Any other characters are
    allowed. Internal lists can be used in .for loops. Examples are DEPENDS and
    BUILD_DEPENDS.

  * External lists are lists that may be exported to a shell command. Their
    elements can contain any characters, including whitespace. That's why they
    cannot be used in .for loops. Examples are DISTFILES and MASTER_SITES.

12.2.1. Naming conventions

  * All variable names starting with an underscore are reserved for use by the
    pkgsrc infrastructure. They shall not be used by package Makefiles.

  * In .for loops you should use lowercase variable names for the iteration
    variables.

  * All list variables should have a ``plural'' name, e.g. PKG_OPTIONS or
    DISTFILES.

12.3. Code snippets

This section presents you with some code snippets you should use in your own
code. If you don't find anything appropriate here, you should test your code
and add it here.

12.3.1. Adding things to a list

STRING= foo * bar `date`
INT_LIST= # empty
ANOTHER_INT_LIST= apache-[0-9]*:../../www/apache
EXT_LIST= # empty
ANOTHER_EXT_LIST= a=b c=d

INT_LIST+= ${STRING} # 1
INT_LIST+= ${ANOTHER_INT_LIST} # 2
EXT_LIST+= ${STRING:Q} # 3
EXT_LIST+= ${ANOTHER_EXT_LIST} # 4

When you add a string to an external list (example 3), it must be quoted. In
all other cases, you must not add a quoting level. You must not merge internal
and external lists, unless you are sure that all entries are correctly
interpreted in both lists.

12.3.2. Converting an internal list into an external list

EXT_LIST= # empty
.for i in ${INT_LIST}
EXT_LIST+= ${i:Q}""
.endfor

This code converts the internal list INT_LIST into the external list EXT_LIST.
As the elements of an internal list are unquoted they must be quoted here. The
reason for appending "" is explained below.

12.3.3. Passing variables to a shell command

Sometimes you may want to print an arbitrary string. There are many ways to get
it wrong and only few that can handle every nastiness.

STRING= foo bar < > * `date` $$HOME ' "
EXT_LIST= string=${STRING:Q} x=second\ item

all:
        echo ${STRING} # 1
        echo "${STRING}" # 2
        echo "${STRING:Q}" # 3
        echo ${STRING:Q} # 4
        echo x${STRING:Q} | sed 1s,.,, # 5
        printf "%s\\n" ${STRING:Q}"" # 6
        env ${EXT_LIST} /bin/sh -c 'echo "$$string"; echo "$$x"'

Example 1 leads to a syntax error in the shell, as the characters are just
copied.

Example 2 leads to a syntax error too, and if you leave out the last "
character from ${STRING}, date(1) will be executed. The $HOME shell variable
would be evaluated, too.

Example 3 outputs each space character preceded by a backslash (or not),
depending on the implementation of the echo(1) command.

Example 4 handles correctly every string that does not start with a dash. In
that case, the result depends on the implementation of the echo(1) command. As
long as you can guarantee that your input does not start with a dash, this form
is appropriate.

Example 5 handles even the case of a leading dash correctly.

Example 6 also works with every string and is the light-weight solution, since
it does not involve a pipe, which has its own problems.

The EXT_LIST does not need to be quoted because the quoting has already been
done when adding elements to the list.

As internal lists shall not be passed to the shell, there is no example for it.

12.3.4. Quoting guideline

There are many possible sources of wrongly quoted variables. This section lists
some of the commonly known ones.

  * Whenever you use the value of a list, think about what happens to leading
    or trailing whitespace. If the list is a well-formed shell expression, you
    can apply the :M* modifier to strip leading and trailing whitespace from
    each word. The :M operator first splits its argument according to the rules
    of the shell, and then creates a new list consisting of all words that
    match the shell glob expression *, that is: all. One class of situations
    where this is needed is when adding a variable like CPPFLAGS to
    CONFIGURE_ARGS. If the configure script invokes other configure scripts, it
    strips the leading and trailing whitespace from the variable and then
    passes it to the other configure scripts. But these configure scripts
    expect the (child) CPPFLAGS variable to be the same as the parent CPPFLAGS.
    That's why we better pass the CPPFLAGS value properly trimmed. And here is
    how we do it:

    CPPFLAGS= # empty
    CPPFLAGS+= -Wundef -DPREFIX=\"${PREFIX:Q}\"
    CPPFLAGS+= ${MY_CPPFLAGS}

    CONFIGURE_ARGS+= CPPFLAGS=${CPPFLAGS:M*:Q}

    all:
            echo x${CPPFLAGS:Q}x # leading and trailing whitespace
            echo x${CONFIGURE_ARGS}x # properly trimmed

  * The example above contains one bug: The ${PREFIX} is a properly quoted
    shell expression, but there is the C compiler after it, which also expects
    a properly quoted string (this time in C syntax). The version above is
    therefore only correct if ${PREFIX} does not have embedded backslashes or
    double quotes. If you want to allow these, you have to add another layer of
    quoting to each variable that is used as a C string literal. You cannot use
    the :Q operator for it, as this operator only works for the shell.

  * Whenever a variable can be empty, the :Q operator can have surprising
    results. Here are two completely different cases which can be solved with
    the same trick.

    EMPTY= # empty
    empty_test:
            for i in a ${EMPTY:Q} c; do \
                echo "$$i"; \
            done

    for_test:
    .for i in a:\ a:\test.txt
            echo ${i:Q}
            echo "foo"
    .endfor

    The first example will only print two of the three lines we might have
    expected. This is because ${EMPTY:Q} expands to the empty string, which the
    shell cannot see. The workaround is to write ${EMPTY:Q}"". This pattern can
    be often found as ${TEST} -z ${VAR:Q} or as ${TEST} -f ${FNAME:Q} (both of
    these are wrong).

    The second example will only print three lines instead of four. The first
    line looks like a:\ echo foo. This is because the backslash of the value a:
    \ is interpreted as a line-continuation by make(1), which makes the second
    line the arguments of the echo(1) command from the first line. To avoid
    this, write ${i:Q}"".

12.3.5. Workaround for a bug in BSD Make

The pkgsrc bmake program does not handle the following assignment correctly. In
case _othervar_ contains a ``-'' character, one of the closing braces is
included in ${VAR} after this code executes.

VAR:= ${VAR:N${_othervar_:C/-//}}

For a more complex code snippet and a workaround, see the package regress/
make-quoting, testcase bug1.

Chapter 13. PLIST issues

Table of Contents

13.1. RCS ID
13.2. Semi-automatic PLIST generation
13.3. Tweaking output of make print-PLIST
13.4. Variable substitution in PLIST
13.5. Man page compression
13.6. Changing PLIST source with PLIST_SRC
13.7. Platform-specific and differing PLISTs
13.8. Sharing directories between packages

The PLIST file contains a package's "packing list", i.e. a list of files that
belong to the package (relative to the ${PREFIX} directory it's been installed
in) plus some additional statements - see the pkg_create(1) man page for a full
list. This chapter addresses some issues that need attention when dealing with
the PLIST file (or files, see below!).

13.1. RCS ID

Be sure to add a RCS ID line as the first thing in any PLIST file you write:

@comment $NetBSD$


13.2. Semi-automatic PLIST generation

You can use the make print-PLIST command to output a PLIST that matches any new
files since the package was extracted. See Section 17.17, "Other helpful
targets" for more information on this target.

13.3. Tweaking output of make print-PLIST

If you have used any of the *-dirs packages, as explained in Section 13.8,
"Sharing directories between packages", you may have noticed that make
print-PLIST outputs a set of @comments instead of real @dirrm lines. You can
also do this for specific directories and files, so that the results of that
command are very close to reality. This helps a lot during the update of
packages.

The PRINT_PLIST_AWK variable takes a set of AWK patterns and actions that are
used to filter the output of print-PLIST. You can append any chunk of AWK
scripting you like to it, but be careful with quoting.

For example, to get all files inside the libdata/foo directory removed from the
resulting PLIST:

PRINT_PLIST_AWK+= /^libdata\/foo/ { next; }


And to get all the @dirrm lines referring to a specific (shared) directory
converted to @comments:

PRINT_PLIST_AWK+= /^@dirrm share\/specific/ { print "@comment " $$0; next; }


13.4. Variable substitution in PLIST

A number of variables are substituted automatically in PLISTs when a package is
installed on a system. This includes the following variables:

${MACHINE_ARCH}, ${MACHINE_GNU_ARCH}

    Some packages like emacs and perl embed information about which
    architecture they were built on into the pathnames where they install their
    files. To handle this case, PLIST will be preprocessed before actually
    used, and the symbol "${MACHINE_ARCH}" will be replaced by what uname -p
    gives. The same is done if the string ${MACHINE_GNU_ARCH} is embedded in
    PLIST somewhere - use this on packages that have GNU autoconf-created
    configure scripts.

    Legacy note

    There used to be a symbol "$ARCH" that was replaced by the output of uname
    -m, but that's no longer supported and has been removed.

${OPSYS}, ${LOWER_OPSYS}, ${OS_VERSION}

    Some packages want to embed the OS name and version into some paths. To do
    this, use these variables in the PLIST:

      * ${OPSYS} - output of "uname -s"

      * ${LOWER_OPSYS} - lowercase common name (eg. "solaris")

      * ${OS_VERSION} - "uname -r"

For a complete list of values which are replaced by default, please look in
bsd.pkg.mk (and search for PLIST_SUBST).

If you want to change other variables not listed above, you can add variables
and their expansions to this variable in the following way, similar to
MESSAGE_SUBST (see Section 11.5, "Optional files"):

PLIST_SUBST+= SOMEVAR="somevalue"


This replaces all occurrences of "${SOMEVAR}" in the PLIST with "somevalue".

The PLIST_VARS variable can be used to simplify the common case of
conditionally including some PLIST entries. It can be done by adding
PLIST_VARS+=foo and setting the corresponding PLIST.foo variable to yes if the
entry should be included. This will substitute "${PLIST.foo}" in the PLIST with
either """" or ""@comment "". For example, in Makefile:

PLIST_VARS+= foo
.if condition
PLIST.foo= yes
.else


And then in PLIST:

@comment $NetBSD$
bin/bar
man/man1/bar.1
${PLIST.foo}bin/foo
${PLIST.foo}man/man1/foo.1
${PLIST.foo}share/bar/foo.data
${PLIST.foo}@dirrm share/bar


13.5. Man page compression

Man pages should be installed in compressed form if MANZ is set (in
bsd.own.mk), and uncompressed otherwise. To handle this in the PLIST file, the
suffix ".gz" is appended/removed automatically for man pages according to MANZ
and MANCOMPRESSED being set or not, see above for details. This modification of
the PLIST file is done on a copy of it, not PLIST itself.

13.6. Changing PLIST source with PLIST_SRC

To use one or more files as source for the PLIST used in generating the binary
package, set the variable PLIST_SRC to the names of that file(s). The files are
later concatenated using cat(1), and the order of things is important. The
default for PLIST_SRC is ${PKGDIR}/PLIST.

13.7. Platform-specific and differing PLISTs

Some packages decide to install a different set of files based on the operating
system being used. These differences can be automatically handled by using the
following files:

  * PLIST.common

  * PLIST.${OPSYS}

  * PLIST.${MACHINE_ARCH}

  * PLIST.${OPSYS}-${MACHINE_ARCH}

  * PLIST.common_end

13.8. Sharing directories between packages

A "shared directory" is a directory where multiple (and unrelated) packages
install files. These directories were problematic because you had to add
special tricks in the PLIST to conditionally remove them, or have some
centralized package handle them.

In pkgsrc, it is now easy: Each package should create directories and install
files as needed; pkg_delete will remove any directories left empty after
uninstalling a package.

If a package needs an empty directory to work, create the directory during
installation as usual, and also add an entry to the PLIST:

@pkgdir path/to/empty/directory


Chapter 14. Buildlink methodology

Table of Contents

14.1. Converting packages to use buildlink3
14.2. Writing buildlink3.mk files

    14.2.1. Anatomy of a buildlink3.mk file
    14.2.2. Updating BUILDLINK_API_DEPENDS.pkg and BUILDLINK_ABI_DEPENDS.pkg in
        buildlink3.mk files

14.3. Writing builtin.mk files

    14.3.1. Anatomy of a builtin.mk file
    14.3.2. Global preferences for native or pkgsrc software

Buildlink is a framework in pkgsrc that controls what headers and libraries are
seen by a package's configure and build processes. This is implemented in a two
step process:

 1. Symlink headers and libraries for dependencies into BUILDLINK_DIR, which by
    default is a subdirectory of WRKDIR.

 2. Create wrapper scripts that are used in place of the normal compiler tools
    that translate -I${LOCALBASE}/include and -L${LOCALBASE}/lib into
    references to BUILDLINK_DIR. The wrapper scripts also make native compiler
    on some operating systems look like GCC, so that packages that expect GCC
    won't require modifications to build with those native compilers.

This normalizes the environment in which a package is built so that the package
may be built consistently despite what other software may be installed. Please
note that the normal system header and library paths, e.g. /usr/include, /usr/
lib, etc., are always searched -- buildlink3 is designed to insulate the
package build from non-system-supplied software.

14.1. Converting packages to use buildlink3

The process of converting packages to use the buildlink3 framework ("bl3ifying"
) is fairly straightforward. The things to keep in mind are:

 1. Ensure that the build always calls the wrapper scripts instead of the
    actual toolchain. Some packages are tricky, and the only way to know for
    sure is the check ${WRKDIR}/.work.log to see if the wrappers are being
    invoked.

 2. Don't override PREFIX from within the package Makefile, e.g. Java VMs,
    standalone shells, etc., because the code to symlink files into $
    {BUILDLINK_DIR} looks for files relative to "pkg_info -qp pkgname".

 3. Remember that only the buildlink3.mk files that you list in a package's
    Makefile are added as dependencies for that package.

If a dependency on a particular package is required for its libraries and
headers, then we replace:

DEPENDS+= foo>=1.1.0:../../category/foo

with

.include "../../category/foo/buildlink3.mk"

The buildlink3.mk files usually define the required dependencies. If you need a
newer version of the dependency when using buildlink3.mk files, then you can
define it in your Makefile; for example:

BUILDLINK_API_DEPENDS.foo+= foo>=1.1.0
.include "../../category/foo/buildlink3.mk"

There are several buildlink3.mk files in pkgsrc/mk that handle special package
issues:

  * bdb.buildlink3.mk chooses either the native or a pkgsrc Berkeley DB
    implementation based on the values of BDB_ACCEPTED and BDB_DEFAULT.

  * curses.buildlink3.mk: If the system comes with neither Curses nor NCurses,
    this will take care to install the devel/ncurses package.

  * krb5.buildlink3.mk uses the value of KRB5_ACCEPTED to choose between adding
    a dependency on Heimdal or MIT-krb5 for packages that require a Kerberos 5
    implementation.

  * motif.buildlink3.mk checks for a system-provided Motif installation or adds
    a dependency on x11/lesstif or x11/openmotif. The user can set MOTIF_TYPE
    to "dt", "lesstif", or "openmotif" to choose which Motif version will be
    used.

  * oss.buildlink3.mk defines several variables that may be used by packages
    that use the Open Sound System (OSS) API.

  * pgsql.buildlink3.mk will accept any of the Postgres versions in the
    variable PGSQL_VERSIONS_ACCEPTED and default to the version
    PGSQL_VERSION_DEFAULT. See the file for more information.

  * pthread.buildlink3.mk uses the value of PTHREAD_OPTS and checks for native
    pthreads or adds a dependency on devel/pth as needed.

  * xaw.buildlink3.mk uses the value of XAW_TYPE to choose a particular Athena
    widgets library.

The comments in those buildlink3.mk files provide a more complete description
of how to use them properly.

14.2. Writing buildlink3.mk files

A package's buildlink3.mk file is included by Makefiles to indicate the need to
compile and link against header files and libraries provided by the package. A
buildlink3.mk file should always provide enough information to add the correct
type of dependency relationship and include any other buildlink3.mk files that
it needs to find headers and libraries that it needs in turn.

To generate an initial buildlink3.mk file for further editing, Rene Hexel's
pkgtools/createbuildlink package is highly recommended. For most packages, the
following command will generate a good starting point for buildlink3.mk files:

% cd pkgsrc/category/pkgdir
% createbuildlink >buildlink3.mk


14.2.1. Anatomy of a buildlink3.mk file

The following real-life example buildlink3.mk is taken from pkgsrc/graphics/
tiff:

# $NetBSD: buildlink3.mk,v 1.16 2009/03/20 19:24:45 joerg Exp $

BUILDLINK_TREE+= tiff

.if !defined(TIFF_BUILDLINK3_MK)
TIFF_BUILDLINK3_MK:=

BUILDLINK_API_DEPENDS.tiff+= tiff>=3.6.1
BUILDLINK_ABI_DEPENDS.tiff+= tiff>=3.7.2nb1
BUILDLINK_PKGSRCDIR.tiff?= ../../graphics/tiff

.include "../../devel/zlib/buildlink3.mk"
.include "../../graphics/jpeg/buildlink3.mk"
.endif # TIFF_BUILDLINK3_MK

BUILDLINK_TREE+= -tiff

The header and footer manipulate BUILDLINK_TREE, which is common across all
buildlink3.mk files and is used to track the dependency tree.

The main section is protected from multiple inclusion and controls how the
dependency on pkg is added. Several important variables are set in the section:

  * BUILDLINK_API_DEPENDS.pkg is the actual dependency recorded in the
    installed package; this should always be set using += to ensure that we're
    appending to any pre-existing list of values. This variable should be set
    to the first version of the package that had an backwards-incompatible API
    change.

  * BUILDLINK_PKGSRCDIR.pkg is the location of the pkg pkgsrc directory.

  * BUILDLINK_DEPMETHOD.pkg (not shown above) controls whether we use
    BUILD_DEPENDS or DEPENDS to add the dependency on pkg. The build dependency
    is selected by setting BUILDLINK_DEPMETHOD.pkg to "build". By default, the
    full dependency is used.

  * BUILDLINK_INCDIRS.pkg and BUILDLINK_LIBDIRS.pkg (not shown above) are lists
    of subdirectories of ${BUILDLINK_PREFIX.pkg} to add to the header and
    library search paths. These default to "include" and "lib" respectively.

  * BUILDLINK_CPPFLAGS.pkg (not shown above) is the list of preprocessor flags
    to add to CPPFLAGS, which are passed on to the configure and build phases.
    The "-I" option should be avoided and instead be handled using
    BUILDLINK_INCDIRS.pkg as above.

The following variables are all optionally defined within this second section
(protected against multiple inclusion) and control which package files are
symlinked into ${BUILDLINK_DIR} and how their names are transformed during the
symlinking:

  * BUILDLINK_FILES.pkg (not shown above) is a shell glob pattern relative to $
    {BUILDLINK_PREFIX.pkg} to be symlinked into ${BUILDLINK_DIR}, e.g. include/
    *.h.

  * BUILDLINK_FILES_CMD.pkg (not shown above) is a shell pipeline that outputs
    to stdout a list of files relative to ${BUILDLINK_PREFIX.pkg}. The
    resulting files are to be symlinked into ${BUILDLINK_DIR}. By default, this
    takes the +CONTENTS of a pkg and filters it through $
    {BUILDLINK_CONTENTS_FILTER.pkg}.

  * BUILDLINK_CONTENTS_FILTER.pkg (not shown above) is a filter command that
    filters +CONTENTS input into a list of files relative to $
    {BUILDLINK_PREFIX.pkg} on stdout. By default for overwrite packages,
    BUILDLINK_CONTENTS_FILTER.pkg outputs the contents of the include and lib
    directories in the package +CONTENTS, and for pkgviews packages, it outputs
    any libtool archives in lib directories.

  * BUILDLINK_FNAME_TRANSFORM.pkg (not shown above) is a list of sed arguments
    used to transform the name of the source filename into a destination
    filename, e.g. -e "s|/curses.h|/ncurses.h|g".

This section can additionally include any buildlink3.mk needed for pkg's
library dependencies. Including these buildlink3.mk files means that the
headers and libraries for these dependencies are also symlinked into $
{BUILDLINK_DIR} whenever the pkg buildlink3.mk file is included. Dependencies
are only added for directly include buildlink3.mk files.

14.2.2. Updating BUILDLINK_API_DEPENDS.pkg and BUILDLINK_ABI_DEPENDS.pkg in
buildlink3.mk files

These two variables differ in that one describes source compatibility (API) and
the other binary compatibility (ABI). The difference is that a change in the
API breaks compilation of programs while changes in the ABI stop compiled
programs from running.

Changes to the BUILDLINK_API_DEPENDS.pkg variable in a buildlink3.mk file
happen very rarely. One possible reason is that all packages depending on this
already need a newer version. In case it is bumped see the description below.

The most common example of an ABI change is that the major version of a shared
library is increased. In this case, BUILDLINK_ABI_DEPENDS.pkg should be
adjusted to require at least the new package version. Then the packages that
depend on this package need their PKGREVISIONs increased and, if they have
buildlink3.mk files, their BUILDLINK_ABI_DEPENDS.pkg adjusted, too. This is
needed so pkgsrc will require the correct package dependency and not settle for
an older one when building the source.

See Section 19.1.6, "Handling dependencies" for more information about
dependencies on other packages, including the BUILDLINK_ABI_DEPENDS and
ABI_DEPENDS definitions.

Please take careful consideration before adjusting BUILDLINK_API_DEPENDS.pkg or
BUILDLINK_ABI_DEPENDS.pkg as we don't want to cause unneeded package deletions
and rebuilds. In many cases, new versions of packages work just fine with older
dependencies.

Also it is not needed to set BUILDLINK_ABI_DEPENDS.pkg when it is identical to
BUILDLINK_API_DEPENDS.pkg.

14.3. Writing builtin.mk files

Some packages in pkgsrc install headers and libraries that coincide with
headers and libraries present in the base system. Aside from a buildlink3.mk
file, these packages should also include a builtin.mk file that includes the
necessary checks to decide whether using the built-in software or the pkgsrc
software is appropriate.

The only requirements of a builtin.mk file for pkg are:

 1. It should set USE_BUILTIN.pkg to either "yes" or "no" after it is included.

 2. It should not override any USE_BUILTIN.pkg which is already set before the
    builtin.mk file is included.

 3. It should be written to allow multiple inclusion. This is very important
    and takes careful attention to Makefile coding.

14.3.1. Anatomy of a builtin.mk file

The following is the recommended template for builtin.mk files:

.if !defined(IS_BUILTIN.foo)
#
# IS_BUILTIN.foo is set to "yes" or "no" depending on whether "foo"
# genuinely exists in the system or not.
#
IS_BUILTIN.foo?= no

# BUILTIN_PKG.foo should be set here if "foo" is built-in and its package
# version can be determined.
#
. if !empty(IS_BUILTIN.foo:M[yY][eE][sS])
BUILTIN_PKG.foo?= foo-1.0
. endif
.endif # IS_BUILTIN.foo

.if !defined(USE_BUILTIN.foo)
USE_BUILTIN.foo?= ${IS_BUILTIN.foo}
. if defined(BUILTIN_PKG.foo)
. for _depend_ in ${BUILDLINK_API_DEPENDS.foo}
. if !empty(USE_BUILTIN.foo:M[yY][eE][sS])
USE_BUILTIN.foo!= \
        ${PKG_ADMIN} pmatch '${_depend_}' ${BUILTIN_PKG.foo} \
        && ${ECHO} "yes" || ${ECHO} "no"
. endif
. endfor
. endif
.endif # USE_BUILTIN.foo

CHECK_BUILTIN.foo?= no
.if !empty(CHECK_BUILTIN.foo:M[nN][oO])
#
# Here we place code that depends on whether USE_BUILTIN.foo is set to
# "yes" or "no".
#
.endif # CHECK_BUILTIN.foo

The first section sets IS_BUILTIN.pkg depending on if pkg really exists in the
base system. This should not be a base system software with similar
functionality to pkg; it should only be "yes" if the actual package is included
as part of the base system. This variable is only used internally within the
builtin.mk file.

The second section sets BUILTIN_PKG.pkg to the version of pkg in the base
system if it exists (if IS_BUILTIN.pkg is "yes"). This variable is only used
internally within the builtin.mk file.

The third section sets USE_BUILTIN.pkg and is required in all builtin.mk files.
The code in this section must make the determination whether the built-in
software is adequate to satisfy the dependencies listed in
BUILDLINK_API_DEPENDS.pkg. This is typically done by comparing BUILTIN_PKG.pkg
against each of the dependencies in BUILDLINK_API_DEPENDS.pkg. USE_BUILTIN.pkg
must be set to the correct value by the end of the builtin.mk file. Note that
USE_BUILTIN.pkg may be "yes" even if IS_BUILTIN.pkg is "no" because we may make
the determination that the built-in version of the software is similar enough
to be used as a replacement.

The last section is guarded by CHECK_BUILTIN.pkg, and includes code that uses
the value of USE_BUILTIN.pkg set in the previous section. This typically
includes, e.g., adding additional dependency restrictions and listing
additional files to symlink into ${BUILDLINK_DIR} (via BUILDLINK_FILES.pkg).

14.3.2. Global preferences for native or pkgsrc software

When building packages, it's possible to choose whether to set a global
preference for using either the built-in (native) version or the pkgsrc version
of software to satisfy a dependency. This is controlled by setting
PREFER_PKGSRC and PREFER_NATIVE. These variables take values of either "yes", "
no", or a list of packages. PREFER_PKGSRC tells pkgsrc to use the pkgsrc
versions of software, while PREFER_NATIVE tells pkgsrc to use the built-in
versions. Preferences are determined by the most specific instance of the
package in either PREFER_PKGSRC or PREFER_NATIVE. If a package is specified in
neither or in both variables, then PREFER_PKGSRC has precedence over
PREFER_NATIVE. For example, to require using pkgsrc versions of software for
all but the most basic bits on a NetBSD system, you can set:

PREFER_PKGSRC= yes
PREFER_NATIVE= getopt skey tcp_wrappers

A package must have a builtin.mk file to be listed in PREFER_NATIVE, otherwise
it is simply ignored in that list.

Chapter 15. The pkginstall framework

Table of Contents

15.1. Files and directories outside the installation prefix

    15.1.1. Directory manipulation
    15.1.2. File manipulation

15.2. Configuration files

    15.2.1. How PKG_SYSCONFDIR is set
    15.2.2. Telling the software where configuration files are
    15.2.3. Patching installations
    15.2.4. Disabling handling of configuration files

15.3. System startup scripts

    15.3.1. Disabling handling of system startup scripts

15.4. System users and groups
15.5. System shells

    15.5.1. Disabling shell registration

15.6. Fonts

    15.6.1. Disabling automatic update of the fonts databases

This chapter describes the framework known as pkginstall, whose key features
are:

  * Generic installation and manipulation of directories and files outside the
    pkgsrc-handled tree, LOCALBASE.

  * Automatic handling of configuration files during installation, provided
    that packages are correctly designed.

  * Generation and installation of system startup scripts.

  * Registration of system users and groups.

  * Registration of system shells.

  * Automatic updating of fonts databases.

The following sections inspect each of the above points in detail.

You may be thinking that many of the things described here could be easily done
with simple code in the package's post-installation target (post-install). This
is incorrect, as the code in them is only executed when building from source.
Machines using binary packages could not benefit from it at all (as the code
itself could be unavailable). Therefore, the only way to achieve any of the
items described above is by means of the installation scripts, which are
automatically generated by pkginstall.

15.1. Files and directories outside the installation prefix

As you already know, the PLIST file holds a list of files and directories that
belong to a package. The names used in it are relative to the installation
prefix (${PREFIX}), which means that it cannot register files outside this
directory (absolute path names are not allowed). Despite this restriction, some
packages need to install files outside this location; e.g., under ${VARBASE} or
${PKG_SYSCONFDIR}. The only way to achieve this is to create such files during
installation time by using installation scripts.

The generic installation scripts are shell scripts that can contain arbitrary
code. The list of scripts to execute is taken from the INSTALL_FILE variable,
which defaults to INSTALL. A similar variable exists for package removal
(DEINSTALL_FILE, whose default is DEINSTALL). These scripts can run arbitrary
commands, so they have the potential to create and manage files anywhere in the
file system.

Using these general installation files is not recommended, but may be needed in
some special cases. One reason for avoiding them is that the user has to trust
the packager that there is no unwanted or simply erroneous code included in the
installation script. Also, previously there were many similar scripts for the
same functionality, and fixing a common error involved finding and changing all
of them.

The pkginstall framework offers another, standardized way. It provides generic
scripts to abstract the manipulation of such files and directories based on
variables set in the package's Makefile. The rest of this section describes
these variables.

15.1.1. Directory manipulation

The following variables can be set to request the creation of directories
anywhere in the file system:

  * MAKE_DIRS and OWN_DIRS contain a list of directories that should be created
    and should attempt to be destroyed by the installation scripts. The
    difference between the two is that the latter prompts the administrator to
    remove any directories that may be left after deinstallation (because they
    were not empty), while the former does not.

  * MAKE_DIRS_PERMS and OWN_DIRS_PERMS contain a list of tuples describing
    which directories should be created and should attempt to be destroyed by
    the installation scripts. Each tuple holds the following values, separated
    by spaces: the directory name, its owner, its group and its numerical mode.
    For example:

    MAKE_DIRS_PERMS+= ${VARBASE}/foo/private ${ROOT_USER} ${ROOT_GROUP} 0700

    The difference between the two is exactly the same as their non-PERMS
    counterparts.

15.1.2. File manipulation

Creating non-empty files outside the installation prefix is tricky because the
PLIST forces all files to be inside it. To overcome this problem, the only
solution is to extract the file in the known place (i.e., inside the
installation prefix) and copy it to the appropriate location during
installation (done by the installation scripts generated by pkginstall). We
will call the former the master file in the following paragraphs, which
describe the variables that can be used to automatically and consistently
handle files outside the installation prefix:

  * CONF_FILES and REQD_FILES are pairs of master and target files. During
    installation time, the master file is copied to the target one if and only
    if the latter does not exist. Upon deinstallation, the target file is
    removed provided that it was not modified by the installation.

    The difference between the two is that the latter prompts the administrator
    to remove any files that may be left after deinstallation (because they
    were not empty), while the former does not.

  * CONF_FILES_PERMS and REQD_FILES_PERMS contain tuples describing master
    files as well as their target locations. For each of them, it also
    specifies their owner, their group and their numeric permissions, in this
    order. For example:

    REQD_FILES_PERMS+= ${PREFIX}/share/somefile ${VARBASE}/somefile ${ROOT_USER} ${ROOT_GROUP} 0700

    The difference between the two is exactly the same as their non-PERMS
    counterparts.

15.2. Configuration files

Configuration files are special in the sense that they are installed in their
own specific directory, PKG_SYSCONFDIR, and need special treatment during
installation (most of which is automated by pkginstall). The main concept you
must bear in mind is that files marked as configuration files are automatically
copied to the right place (somewhere inside PKG_SYSCONFDIR) during installation
if and only if they didn't exist before. Similarly, they will not be removed if
they have local modifications. This ensures that administrators never lose any
custom changes they may have made.

15.2.1. How PKG_SYSCONFDIR is set

As said before, the PKG_SYSCONFDIR variable specifies where configuration files
shall be installed. Its contents are set based upon the following variables:

  * PKG_SYSCONFBASE: The configuration's root directory. Defaults to ${PREFIX}/
    etc although it may be overridden by the user to point to his preferred
    location (e.g., /etc, /etc/pkg, etc.). Packages must not use it directly.

  * PKG_SYSCONFSUBDIR: A subdirectory of PKG_SYSCONFBASE under which the
    configuration files for the package being built shall be installed. The
    definition of this variable only makes sense in the package's Makefile
    (i.e., it is not user-customizable).

    As an example, consider the Apache package, www/apache2, which places its
    configuration files under the httpd/ subdirectory of PKG_SYSCONFBASE. This
    should be set in the package Makefile.

  * PKG_SYSCONFVAR: Specifies the name of the variable that holds this
    package's configuration directory (if different from PKG_SYSCONFBASE). It
    defaults to PKGBASE's value, and is always prefixed with PKG_SYSCONFDIR.

  * PKG_SYSCONFDIR.${PKG_SYSCONFVAR}: Holds the directory where the
    configuration files for the package identified by PKG_SYSCONFVAR's shall be
    placed.

Based on the above variables, pkginstall determines the value of
PKG_SYSCONFDIR, which is the only variable that can be used within a package to
refer to its configuration directory. The algorithm used to set its value is
basically the following:

 1. If PKG_SYSCONFDIR.${PKG_SYSCONFVAR} is set, its value is used.

 2. If the previous variable is not defined but PKG_SYSCONFSUBDIR is set in the
    package's Makefile, the resulting value is ${PKG_SYSCONFBASE}/$
    {PKG_SYSCONFSUBDIR}.

 3. Otherwise, it is set to ${PKG_SYSCONFBASE}.

It is worth mentioning that ${PKG_SYSCONFDIR} is automatically added to
OWN_DIRS. See Section 15.1.1, "Directory manipulation" what this means. This
does not apply to subdirectories of ${PKG_SYSCONFDIR}, they still have to be
created with OWN_DIRS or MAKE_DIRS.

15.2.2. Telling the software where configuration files are

Given that pkgsrc (and users!) expect configuration files to be in a known
place, you need to teach each package where it shall install its files. In some
cases you will have to patch the package Makefiles to achieve it. If you are
lucky, though, it may be as easy as passing an extra flag to the configuration
script; this is the case of GNU Autoconf- generated files:

CONFIGURE_ARGS+= --sysconfdir=${PKG_SYSCONFDIR}

Note that this specifies where the package has to look for its configuration
files, not where they will be originally installed (although the difference is
never explicit, unfortunately).

15.2.3. Patching installations

As said before, pkginstall automatically handles configuration files. This
means that the packages themselves must not touch the contents of $
{PKG_SYSCONFDIR} directly. Bad news is that many software installation scripts
will, out of the box, mess with the contents of that directory. So what is the
correct procedure to fix this issue?

You must teach the package (usually by manually patching it) to install any
configuration files under the examples hierarchy, share/examples/${PKGBASE}/.
This way, the PLIST registers them and the administrator always has the
original copies available.

Once the required configuration files are in place (i.e., under the examples
hierarchy), the pkginstall framework can use them as master copies during the
package installation to update what is in ${PKG_SYSCONFDIR}. To achieve this,
the variables CONF_FILES and CONF_FILES_PERMS are used. Check out
Section 15.1.2, "File manipulation" for information about their syntax and
their purpose. Here is an example, taken from the mail/mutt package:

EGDIR= ${PREFIX}/share/doc/mutt/samples
CONF_FILES= ${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc

Note that the EGDIR variable is specific to that package and has no meaning
outside it.

15.2.4. Disabling handling of configuration files

The automatic copying of config files can be toggled by setting the environment
variable PKG_CONFIG prior to package installation.

15.3. System startup scripts

System startup scripts are special files because they must be installed in a
place known by the underlying OS, usually outside the installation prefix.
Therefore, the same rules described in Section 15.1, "Files and directories
outside the installation prefix" apply, and the same solutions can be used.
However, pkginstall provides a special mechanism to handle these files.

In order to provide system startup scripts, the package has to:

 1. Store the script inside ${FILESDIR}, with the .sh suffix appended.
    Considering the print/cups package as an example, it has a cupsd.sh in its
    files directory.

 2. Tell pkginstall to handle it, appending the name of the script, without its
    extension, to the RCD_SCRIPTS variable. Continuing the previous example:

    RCD_SCRIPTS+= cupsd

Once this is done, pkginstall will do the following steps for each script in an
automated fashion:

 1. Process the file found in the files directory applying all the
    substitutions described in the FILES_SUBST variable.

 2. Copy the script from the files directory to the examples hierarchy, $
    {PREFIX}/share/examples/rc.d/. Note that this master file must be
    explicitly registered in the PLIST.

 3. Add code to the installation scripts to copy the startup script from the
    examples hierarchy into the system-wide startup scripts directory.

15.3.1. Disabling handling of system startup scripts

The automatic copying of config files can be toggled by setting the environment
variable PKG_RCD_SCRIPTS prior to package installation. Note that the scripts
will be always copied inside the examples hierarchy, ${PREFIX}/share/examples/
rc.d/, no matter what the value of this variable is.

15.4. System users and groups

If a package needs to create special users and/or groups during installation,
it can do so by using the pkginstall framework.

Users can be created by adding entries to the PKG_USERS variable. Each entry
has the following syntax:

user:group

Further specification of user details may be done by setting per-user
variables. PKG_UID.user is the numeric UID for the user. PKG_GECOS.user is the
user's description or comment. PKG_HOME.user is the user's home directory, and
defaults to /nonexistent if not specified. PKG_SHELL.user is the user's shell,
and defaults to /sbin/nologin if not specified.

Similarly, groups can be created by adding entries to the PKG_GROUPS variable,
whose syntax is:

group

The numeric GID of the group may be set by defining PKG_GID.group.

If a package needs to create the users and groups at an earlier stage, then it
can set USERGROUP_PHASE to either configure or build to indicate the phase
before which the users and groups are created. In this case, the numeric UIDs
and GIDs of the created users and groups are automatically hardcoded into the
final installation scripts.

15.5. System shells

Packages that install system shells should register them in the shell database,
/etc/shells, to make things easier to the administrator. This must be done from
the installation scripts to keep binary packages working on any system.
pkginstall provides an easy way to accomplish this task.

When a package provides a shell interpreter, it has to set the PKG_SHELL
variable to its absolute file name. This will add some hooks to the
installation scripts to handle it. Consider the following example, taken from
shells/zsh:

PKG_SHELL= ${PREFIX}/bin/zsh

15.5.1. Disabling shell registration

The automatic registration of shell interpreters can be disabled by the
administrator by setting the PKG_REGISTER_SHELLS environment variable to NO.

15.6. Fonts

Packages that install X11 fonts should update the database files that index the
fonts within each fonts directory. This can easily be accomplished within the
pkginstall framework.

When a package installs X11 fonts, it must list the directories in which fonts
are installed in the FONTS_DIRS.type variables, where type can be one of "ttf",
"type1" or "x11". This will add hooks to the installation scripts to run the
appropriate commands to update the fonts database files within each of those
directories. For convenience, if the directory path is relative, it is taken to
be relative to the package's installation prefix. Consider the following
example, taken from fonts/dbz-ttf:

FONTS_DIRS.ttf= ${PREFIX}/lib/X11/fonts/TTF

15.6.1. Disabling automatic update of the fonts databases

The automatic update of fonts databases can be disabled by the administrator by
setting the PKG_UPDATE_FONTS_DB environment variable to NO.

Chapter 16. Options handling

Table of Contents

16.1. Global default options
16.2. Converting packages to use bsd.options.mk
16.3. Option Names
16.4. Determining the options of dependencies

Many packages have the ability to be built to support different sets of
features. bsd.options.mk is a framework in pkgsrc that provides generic
handling of those options that determine different ways in which the packages
can be built. It's possible for the user to specify exactly which sets of
options will be built into a package or to allow a set of global default
options apply.

There are two broad classes of behaviors that one might want to control via
options. One is whether some particular feature is enabled in a program that
will be built anyway, often by including or not including a dependency on some
other package. The other is whether or not an additional program will be built
as part of the package. Generally, it is better to make a split package for
such additional programs instead of using options, because it enables binary
packages to be built which can then be added separately. For example, the foo
package might have minimal dependencies (those packages without which foo
doesn't make sense), and then the foo-gfoo package might include the GTK
frontend program gfoo. This is better than including a gtk option to foo that
adds gfoo, because either that option is default, in which case binary users
can't get foo without gfoo, or not default, in which case they can't get gfoo.
With split packages, they can install foo without having GTK, and later decide
to install gfoo (pulling in GTK at that time). This is an advantage to source
users too, avoiding the need for rebuilds.

Plugins with widely varying dependencies should usually be split instead of
options.

It is often more work to maintain split packages, especially if the upstream
package does not support this. The decision of split vs. option should be made
based on the likelihood that users will want or object to the various pieces,
the size of the dependencies that are included, and the amount of work.

A further consideration is licensing. Non-free parts, or parts that depend on
non-free dependencies (especially plugins) should almost always be split if
feasible.

16.1. Global default options

Global default options are listed in PKG_DEFAULT_OPTIONS, which is a list of
the options that should be built into every package if that option is
supported. This variable should be set in mk.conf.

16.2. Converting packages to use bsd.options.mk

The following example shows how bsd.options.mk should be used by the
hypothetical ``wibble'' package, either in the package Makefile, or in a file,
e.g. options.mk, that is included by the main package Makefile.

PKG_OPTIONS_VAR= PKG_OPTIONS.wibble
PKG_SUPPORTED_OPTIONS= wibble-foo ldap
PKG_OPTIONS_OPTIONAL_GROUPS= database
PKG_OPTIONS_GROUP.database= mysql pgsql
PKG_SUGGESTED_OPTIONS= wibble-foo
PKG_OPTIONS_LEGACY_VARS+= WIBBLE_USE_OPENLDAP:ldap
PKG_OPTIONS_LEGACY_OPTS+= foo:wibble-foo

.include "../../mk/bsd.prefs.mk"

# this package was previously named wibble2
.if defined(PKG_OPTIONS.wibble2)
PKG_LEGACY_OPTIONS+= ${PKG_OPTIONS.wibble2}
PKG_OPTIONS_DEPRECATED_WARNINGS+= \
        "Deprecated variable PKG_OPTIONS.wibble2 used, use ${PKG_OPTIONS_VAR} instead."
.endif

.include "../../mk/bsd.options.mk"

# Package-specific option-handling

###
### FOO support
###
.if !empty(PKG_OPTIONS:Mwibble-foo)
CONFIGURE_ARGS+= --enable-foo
.endif

###
### LDAP support
###
.if !empty(PKG_OPTIONS:Mldap)
. include "../../databases/openldap-client/buildlink3.mk"
CONFIGURE_ARGS+= --enable-ldap=${BUILDLINK_PREFIX.openldap-client}
.endif

###
### database support
###
.if !empty(PKG_OPTIONS:Mmysql)
. include "../../mk/mysql.buildlink3.mk"
.endif
.if !empty(PKG_OPTIONS:Mpgsql)
. include "../../mk/pgsql.buildlink3.mk"
.endif

The first section contains the information about which build options are
supported by the package, and any default options settings if needed.

 1. PKG_OPTIONS_VAR is the name of the make(1) variable that the user can set
    to override the default options. It should be set to PKG_OPTIONS.pkgbase.
    Do not set it to PKG_OPTIONS.${PKGBASE}, since PKGBASE is not defined at
    the point where the options are processed.

 2. PKG_SUPPORTED_OPTIONS is a list of build options supported by the package.

 3. PKG_OPTIONS_OPTIONAL_GROUPS is a list of names of groups of mutually
    exclusive options. The options in each group are listed in
    PKG_OPTIONS_GROUP.groupname. The most specific setting of any option from
    the group takes precedence over all other options in the group. Options
    from the groups will be automatically added to PKG_SUPPORTED_OPTIONS.

 4. PKG_OPTIONS_REQUIRED_GROUPS is like PKG_OPTIONS_OPTIONAL_GROUPS, but
    building the packages will fail if no option from the group is selected.

 5. PKG_OPTIONS_NONEMPTY_SETS is a list of names of sets of options. At least
    one option from each set must be selected. The options in each set are
    listed in PKG_OPTIONS_SET.setname. Options from the sets will be
    automatically added to PKG_SUPPORTED_OPTIONS. Building the package will
    fail if no option from the set is selected.

 6. PKG_SUGGESTED_OPTIONS is a list of build options which are enabled by
    default.

 7. PKG_OPTIONS_LEGACY_VARS is a list of "USE_VARIABLE:option" pairs that map
    legacy mk.conf variables to their option counterparts. Pairs should be
    added with "+=" to keep the listing of global legacy variables. A warning
    will be issued if the user uses a legacy variable.

 8. PKG_OPTIONS_LEGACY_OPTS is a list of "old-option:new-option" pairs that map
    options that have been renamed to their new counterparts. Pairs should be
    added with "+=" to keep the listing of global legacy options. A warning
    will be issued if the user uses a legacy option.

 9. PKG_LEGACY_OPTIONS is a list of options implied by deprecated variables
    used. This can be used for cases that neither PKG_OPTIONS_LEGACY_VARS nor
    PKG_OPTIONS_LEGACY_OPTS can handle, e. g. when PKG_OPTIONS_VAR is renamed.

10. PKG_OPTIONS_DEPRECATED_WARNINGS is a list of warnings about deprecated
    variables or options used, and what to use instead.

A package should never modify PKG_DEFAULT_OPTIONS or the variable named in
PKG_OPTIONS_VAR. These are strictly user-settable. To suggest a default set of
options, use PKG_SUGGESTED_OPTIONS.

PKG_OPTIONS_VAR must be defined before including bsd.options.mk. If none of
PKG_SUPPORTED_OPTIONS, PKG_OPTIONS_OPTIONAL_GROUPS, and
PKG_OPTIONS_REQUIRED_GROUPS are defined (as can happen with platform-specific
options if none of them is supported on the current platform), PKG_OPTIONS is
set to the empty list and the package is otherwise treated as not using the
options framework.

After the inclusion of bsd.options.mk, the variable PKG_OPTIONS contains the
list of selected build options, properly filtered to remove unsupported and
duplicate options.

The remaining sections contain the logic that is specific to each option. The
correct way to check for an option is to check whether it is listed in
PKG_OPTIONS:

.if !empty(PKG_OPTIONS:Moption)

16.3. Option Names

Options that enable similar features in different packages (like optional
support for a library) should use a common name in all packages that support it
(like the name of the library). If another package already has an option with
the same meaning, use the same name.

Options that enable features specific to one package, where it's unlikely that
another (unrelated) package has the same (or a similar) optional feature,
should use a name prefixed with pkgname-.

If a group of related packages share an optional feature specific to that
group, prefix it with the name of the "main" package (e. g.
djbware-errno-hack).

For new options, add a line to mk/defaults/options.description. Lines have two
fields, separated by tab. The first field is the option name, the second its
description. The description should be a whole sentence (starting with an
uppercase letter and ending with a period) that describes what enabling the
option does. E. g. "Enable ispell support." The file is sorted by option names.

16.4. Determining the options of dependencies

When writing buildlink3.mk files, it is often necessary to list different
dependencies based on the options with which the package was built. For
querying these options, the file pkgsrc/mk/pkg-build-options.mk should be used.
A typical example looks like this:

pkgbase := libpurple
.include "../../mk/pkg-build-options.mk"

.if !empty(PKG_BUILD_OPTIONS.libpurple:Mdbus)
...
.endif

Including pkg-build-options.mk here will set the variable
PKG_BUILD_OPTIONS.libpurple to the build options of the libpurple package,
which can then be queried like PKG_OPTIONS in the options.mk file. See the file
pkg-build-options.mk for more details.

Chapter 17. The build process

Table of Contents

17.1. Introduction
17.2. Program location
17.3. Directories used during the build process
17.4. Running a phase
17.5. The fetch phase

    17.5.1. What to fetch and where to get it from
    17.5.2. How are the files fetched?

17.6. The checksum phase
17.7. The extract phase
17.8. The patch phase
17.9. The tools phase
17.10. The wrapper phase
17.11. The configure phase
17.12. The build phase
17.13. The test phase
17.14. The install phase
17.15. The package phase
17.16. Cleaning up
17.17. Other helpful targets

17.1. Introduction

This chapter gives a detailed description on how a package is built. Building a
package is separated into different phases (for example fetch, build, install),
all of which are described in the following sections. Each phase is split into
so-called stages, which take the name of the containing phase, prefixed by one
of pre-, do- or post-. (Examples are pre-configure, post-build.) Most of the
actual work is done in the do-* stages.

Never override the regular targets (like fetch), if you have to, override the
do-* ones instead.

The basic steps for building a program are always the same. First the program's
source (distfile) must be brought to the local system and then extracted. After
any pkgsrc-specific patches to compile properly are applied, the software can
be configured, then built (usually by compiling), and finally the generated
binaries, etc. can be put into place on the system.

To get more details about what is happening at each step, you can set the
PKG_VERBOSE variable, or the PATCH_DEBUG variable if you are just interested in
more details about the patch step.

17.2. Program location

Before outlining the process performed by the NetBSD package system in the next
section, here's a brief discussion on where programs are installed, and which
variables influence this.

The automatic variable PREFIX indicates where all files of the final program
shall be installed. It is usually set to LOCALBASE (/usr/pkg), or CROSSBASE for
pkgs in the cross category. The value of PREFIX needs to be put into the
various places in the program's source where paths to these files are encoded.
See Section 11.3, "patches/*" and Section 19.3.1, "Shared libraries - libtool"
for more details.

When choosing which of these variables to use, follow the following rules:

  * PREFIX always points to the location where the current pkg will be
    installed. When referring to a pkg's own installation path, use "${PREFIX}"
    .

  * LOCALBASE is where all non-X11 pkgs are installed. If you need to construct
    a -I or -L argument to the compiler to find includes and libraries
    installed by another non-X11 pkg, use "${LOCALBASE}". The name LOCALBASE
    stems from FreeBSD, which installed all packages in /usr/local. As pkgsrc
    leaves /usr/local for the system administrator, this variable is a
    misnomer.

  * X11BASE is where the actual X11 distribution (from xsrc, etc.) is
    installed. When looking for standard X11 includes (not those installed by a
    package), use "${X11BASE}".

  * X11-based packages are special in that they may be installed in either
    X11BASE or LOCALBASE.

    Usually, X11 packages should be installed under LOCALBASE whenever
    possible. Note that you will need to include ../../mk/x11.buildlink3.mk in
    them to request the presence of X11 and to get the right compilation flags.

    Even though, there are some packages that cannot be installed under
    LOCALBASE: those that come with app-defaults files. These packages are
    special and they must be placed under X11BASE. To accomplish this, set
    either USE_X11BASE or USE_IMAKE in your package.

    Some notes: If you need to find includes or libraries installed by a pkg
    that has USE_IMAKE or USE_X11BASE in its pkg Makefile, you need to look in
    both ${X11BASE} and ${LOCALBASE}. To force installation of all X11 packages
    in LOCALBASE, the pkgtools/xpkgwedge package is enabled by default.

  * X11PREFIX should be used to refer to the installed location of an X11
    package. X11PREFIX will be set to X11BASE if xpkgwedge is not installed,
    and to LOCALBASE if xpkgwedge is installed.

  * If xpkgwedge is installed, it is possible to have some packages installed
    in X11BASE and some in LOCALBASE. To determine the prefix of an installed
    package, the EVAL_PREFIX definition can be used. It takes pairs in the
    format "DIRNAME=<package>", and the make(1) variable DIRNAME will be set to
    the prefix of the installed package <package>, or "${X11PREFIX}" if the
    package is not installed.

    This is best illustrated by example.

    The following lines are taken from pkgsrc/wm/scwm/Makefile:

    EVAL_PREFIX+= GTKDIR=gtk+
    CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE:Q}
    CONFIGURE_ARGS+= --with-gtk-prefix=${GTKDIR:Q}
    CONFIGURE_ARGS+= --enable-multibyte

    Specific defaults can be defined for the packages evaluated using
    EVAL_PREFIX, by using a definition of the form:

    GTKDIR_DEFAULT= ${LOCALBASE}

    where GTKDIR corresponds to the first definition in the EVAL_PREFIX pair.

  * Within ${PREFIX}, packages should install files according to hier(7), with
    the exception that manual pages go into ${PREFIX}/man, not ${PREFIX}/share/
    man.

17.3. Directories used during the build process

When building a package, various directories are used to store source files,
temporary files, pkgsrc-internal files, and so on. These directories are
explained here.

Some of the directory variables contain relative pathnames. There are two
common base directories for these relative directories: PKGSRCDIR/PKGPATH is
used for directories that are pkgsrc-specific. WRKSRC is used for directories
inside the package itself.

PKGSRCDIR

    This is an absolute pathname that points to the pkgsrc root directory.
    Generally, you don't need it.

PKGDIR

    This is an absolute pathname that points to the current package.

PKGPATH

    This is a pathname relative to PKGSRCDIR that points to the current
    package.

WRKDIR

    This is an absolute pathname pointing to the directory where all work takes
    place. The distfiles are extracted to this directory. It also contains
    temporary directories and log files used by the various pkgsrc frameworks,
    like buildlink or the wrappers.

WRKSRC

    This is an absolute pathname pointing to the directory where the distfiles
    are extracted. It is usually a direct subdirectory of WRKDIR, and often
    it's the only directory entry that isn't hidden. This variable may be
    changed by a package Makefile.

The CREATE_WRKDIR_SYMLINK definition takes either the value yes or no and
defaults to no. It indicates whether a symbolic link to the WRKDIR is to be
created in the pkgsrc entry's directory. If users would like to have their
pkgsrc trees behave in a read-only manner, then the value of
CREATE_WRKDIR_SYMLINK should be set to no.

17.4. Running a phase

You can run a particular phase by typing make phase, where phase is the name of
the phase. This will automatically run all phases that are required for this
phase. The default phase is build, that is, when you run make without
parameters in a package directory, the package will be built, but not
installed.

17.5. The fetch phase

The first step in building a package is to fetch the distribution files
(distfiles) from the sites that are providing them. This is the task of the
fetch phase.

17.5.1. What to fetch and where to get it from

In simple cases, MASTER_SITES defines all URLs from where the distfile, whose
name is derived from the DISTNAME variable, is fetched. The more complicated
cases are described below.

The variable DISTFILES specifies the list of distfiles that have to be fetched.
Its value defaults to ${DISTNAME}${EXTRACT_SUFX}, so that most packages don't
need to define it at all. EXTRACT_SUFX is .tar.gz by default, but can be
changed freely. Note that if your package requires additional distfiles to the
default one, you cannot just append the additional filenames using the +=
operator, but you have write for example:

DISTFILES= ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz

Each distfile is fetched from a list of sites, usually MASTER_SITES. If the
package has multiple DISTFILES or multiple PATCHFILES from different sites, you
can set SITES.distfile to the list of URLs where the file distfile (including
the suffix) can be found.

DISTFILES= ${DISTNAME}${EXTRACT_SUFX}
DISTFILES+= foo-file.tar.gz
SITES.foo-file.tar.gz= \
http://www.somewhere.com/somehow/ \
http://www.somewhereelse.com/mirror/somehow/

When actually fetching the distfiles, each item from MASTER_SITES or SITES.*
gets the name of each distfile appended to it, without an intermediate slash.
Therefore, all site values have to end with a slash or other separator
character. This allows for example to set MASTER_SITES to a URL of a CGI script
that gets the name of the distfile as a parameter. In this case, the definition
would look like:

MASTER_SITES= http://www.example.com/download.cgi?file=

The exception to this rule are URLs starting with a dash. In that case the URL
is taken as is, fetched and the result stored under the name of the distfile.

There are some predefined values for MASTER_SITES, which can be used in
packages. The names of the variables should speak for themselves.

${MASTER_SITE_APACHE}
${MASTER_SITE_BACKUP}
${MASTER_SITE_CYGWIN}
${MASTER_SITE_DEBIAN}
${MASTER_SITE_FREEBSD}
${MASTER_SITE_FREEBSD_LOCAL}
${MASTER_SITE_GENTOO}
${MASTER_SITE_GNOME}
${MASTER_SITE_GNU}
${MASTER_SITE_GNUSTEP}
${MASTER_SITE_IFARCHIVE}
${MASTER_SITE_KDE}
${MASTER_SITE_MOZILLA}
${MASTER_SITE_MYSQL}
${MASTER_SITE_OPENOFFICE}
${MASTER_SITE_PERL_CPAN}
${MASTER_SITE_PGSQL}
${MASTER_SITE_R_CRAN}
${MASTER_SITE_SOURCEFORGE}
${MASTER_SITE_SOURCEFORGE_JP}
${MASTER_SITE_SUNSITE}
${MASTER_SITE_SUSE}
${MASTER_SITE_TEX_CTAN}
${MASTER_SITE_XCONTRIB}
${MASTER_SITE_XEMACS}

Some explanations for the less self-explaining ones: MASTER_SITE_BACKUP
contains backup sites for packages that are maintained in ftp://ftp.NetBSD.org/
pub/pkgsrc/distfiles/${DIST_SUBDIR}. MASTER_SITE_LOCAL contains local package
source distributions that are maintained in ftp://ftp.NetBSD.org/pub/pkgsrc/
distfiles/LOCAL_PORTS/.

If you choose one of these predefined sites, you may want to specify a
subdirectory of that site. Since these macros may expand to more than one
actual site, you must use the following construct to specify a subdirectory:

MASTER_SITES= ${MASTER_SITE_GNU:=subdirectory/name/}
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=project_name/}

Note the trailing slash after the subdirectory name.

17.5.2. How are the files fetched?

The fetch phase makes sure that all the distfiles exist in a local directory
(DISTDIR, which can be set by the pkgsrc user). If the files do not exist, they
are fetched using commands of the form

${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}

where ${site} varies through several possibilities in turn: first,
MASTER_SITE_OVERRIDE is tried, then the sites specified in either SITES.file if
defined, else MASTER_SITES or PATCH_SITES, as applies, then finally the value
of MASTER_SITE_BACKUP. The order of all except the first and the last can be
optionally sorted by the user, via setting either MASTER_SORT_RANDOM, and
MASTER_SORT_AWK or MASTER_SORT_REGEX.

The specific command and arguments used depend on the FETCH_USING parameter.
The example above is for FETCH_USING=custom.

The distfiles mirror run by the NetBSD Foundation uses the mirror-distfiles
target to mirror the distfiles, if they are freely distributable. Packages
setting NO_SRC_ON_FTP (usually to "${RESTRICTED}") will not have their
distfiles mirrored.

17.6. The checksum phase

After the distfile(s) are fetched, their checksum is generated and compared
with the checksums stored in the distinfo file. If the checksums don't match,
the build is aborted. This is to ensure the same distfile is used for building,
and that the distfile wasn't changed, e.g. by some malign force, deliberately
changed distfiles on the master distribution site or network lossage.

17.7. The extract phase

When the distfiles are present on the local system, they need to be extracted,
as they usually come in the form of some compressed archive format.

By default, all DISTFILES are extracted. If you only need some of them, you can
set the EXTRACT_ONLY variable to the list of those files.

Extracting the files is usually done by a little program, mk/extract/extract,
which already knows how to extract various archive formats, so most likely you
will not need to change anything here. But if you need, the following variables
may help you:

EXTRACT_OPTS_{BIN,LHA,PAX,RAR,TAR,ZIP,ZOO}

    Use these variables to override the default options for an extract command,
    which are defined in mk/extract/extract.

EXTRACT_USING

    This variable can be set to bsdtar, gtar, nbtar (which is the default
    value), pax, or an absolute pathname pointing to the command with which tar
    archives should be extracted. It is preferred to choose bsdtar over gtar if
    NetBSD's pax-as-tar is not good enough.

If the extract program doesn't serve your needs, you can also override the
EXTRACT_CMD variable, which holds the command used for extracting the files.
This command is executed in the ${WRKSRC} directory. During execution of this
command, the shell variable extract_file holds the absolute pathname of the
file that is going to be extracted.

And if that still does not suffice, you can override the do-extract target in
the package Makefile.

17.8. The patch phase

After extraction, all the patches named by the PATCHFILES, those present in the
patches subdirectory of the package as well as in $LOCALPATCHES/$PKGPATH (e.g.
/usr/local/patches/graphics/png) are applied. Patchfiles ending in .Z or .gz
are uncompressed before they are applied, files ending in .orig or .rej are
ignored. Any special options to patch(1) can be handed in PATCH_DIST_ARGS. See
Section 11.3, "patches/*" for more details.

By default patch(1) is given special args to make it fail if the patches apply
with some lines of fuzz. Please fix (regen) the patches so that they apply
cleanly. The rationale behind this is that patches that don't apply cleanly may
end up being applied in the wrong place, and cause severe harm there.

17.9. The tools phase

This is covered in Chapter 18, Tools needed for building or running.

17.10. The wrapper phase

This phase creates wrapper programs for the compilers and linkers. The
following variables can be used to tweak the wrappers.

ECHO_WRAPPER_MSG

    The command used to print progress messages. Does nothing by default. Set
    to ${ECHO} to see the progress messages.

WRAPPER_DEBUG

    This variable can be set to yes (default) or no, depending on whether you
    want additional information in the wrapper log file.

WRAPPER_UPDATE_CACHE

    This variable can be set to yes or no, depending on whether the wrapper
    should use its cache, which will improve the speed. The default value is
    yes, but is forced to no if the platform does not support it.

WRAPPER_REORDER_CMDS

    A list of reordering commands. A reordering command has the form reorder:l:
    lib1:lib2. It ensures that that -llib1 occurs before -llib2.

WRAPPER_TRANSFORM_CMDS

    A list of transformation commands. [TODO: investigate further]

17.11. The configure phase

Most pieces of software need information on the header files, system calls, and
library routines which are available on the platform they run on. The process
of determining this information is known as configuration, and is usually
automated. In most cases, a script is supplied with the distfiles, and its
invocation results in generation of header files, Makefiles, etc.

If the package contains a configure script, this can be invoked by setting
HAS_CONFIGURE to "yes". If the configure script is a GNU autoconf script, you
should set GNU_CONFIGURE to "yes" instead. What happens in the configure phase
is roughly:

.for d in ${CONFIGURE_DIRS}
        cd ${WRKSRC} \
        && cd ${d} \
        && env ${CONFIGURE_ENV} ${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS}
.endfor

CONFIGURE_DIRS (default: ".") is a list of pathnames relative to WRKSRC. In
each of these directories, the configure script is run with the environment
CONFIGURE_ENV and arguments CONFIGURE_ARGS. The variables CONFIGURE_ENV,
CONFIGURE_SCRIPT (default: "./configure") and CONFIGURE_ARGS may all be changed
by the package.

If the program uses the Perl way of configuration (mainly Perl modules, but not
only), i.e. a file called Makefile.PL, it should include ../../lang/perl5/
module.mk. To set any parameter for Makefile.PL use the MAKE_PARAMS variable
(e.g., MAKE_PARAMS+=foo=bar

If the program uses an Imakefile for configuration, the appropriate steps can
be invoked by setting USE_IMAKE to "yes". (If you only want the package
installed in ${X11PREFIX} but xmkmf not being run, set USE_X11BASE instead.)
You can add variables to xmkmf's environment by adding them to the SCRIPTS_ENV
variable.

If the program uses cmake for configuration, the appropriate steps can be
invoked by setting USE_CMAKE to "yes". You can add variables to cmake's
environment by adding them to the CONFIGURE_ENV variable and arguments to cmake
by adding them to the CMAKE_ARGS variable. The top directory argument is given
by the CMAKE_ARG_PATH variable, that defaults to "." (relative to
CONFIGURE_DIRS)

If there is no configure step at all, set NO_CONFIGURE to "yes".

17.12. The build phase

For building a package, a rough equivalent of the following code is executed.

.for d in ${BUILD_DIRS}
        cd ${WRKSRC} \
        && cd ${d} \
        && env ${MAKE_ENV} \
            ${MAKE_PROGRAM} ${BUILD_MAKE_FLAGS} \
                -f ${MAKE_FILE} \
                ${BUILD_TARGET}
.endfor

BUILD_DIRS (default: ".") is a list of pathnames relative to WRKSRC. In each of
these directories, MAKE_PROGRAM is run with the environment MAKE_ENV and
arguments BUILD_MAKE_FLAGS. The variables MAKE_ENV, BUILD_MAKE_FLAGS, MAKE_FILE
and BUILD_TARGET may all be changed by the package.

The default value of MAKE_PROGRAM is "gmake" if USE_TOOLS contains "gmake", "
make" otherwise. The default value of MAKE_FILE is "Makefile", and BUILD_TARGET
defaults to "all".

If there is no build step at all, set NO_BUILD to "yes".

17.13. The test phase

[TODO]

17.14. The install phase

Once the build stage has completed, the final step is to install the software
in public directories, so users can access the programs and files.

In the install phase, a rough equivalent of the following code is executed.
Additionally, before and after this code, much magic is performed to do
consistency checks, registering the package, and so on.

.for d in ${INSTALL_DIRS}
        cd ${WRKSRC} \
        && cd ${d} \
        && env ${MAKE_ENV} \
            ${MAKE_PROGRAM} ${INSTALL_MAKE_FLAGS} \
                -f ${MAKE_FILE} \
                ${INSTALL_TARGET}
.endfor

The variable's meanings are analogous to the ones in the build phase.
INSTALL_DIRS defaults to BUILD_DIRS. INSTALL_TARGET is "install" by default,
plus "install.man" if USE_IMAKE is defined and NO_INSTALL_MANPAGES is not
defined.

In the install phase, the following variables are useful. They are all
variations of the install(1) command that have the owner, group and permissions
preset. INSTALL is the plain install command. The specialized variants,
together with their intended use, are:

INSTALL_PROGRAM_DIR

    directories that contain binaries

INSTALL_SCRIPT_DIR

    directories that contain scripts

INSTALL_LIB_DIR

    directories that contain shared and static libraries

INSTALL_DATA_DIR

    directories that contain data files

INSTALL_MAN_DIR

    directories that contain man pages

INSTALL_PROGRAM

    binaries that can be stripped from debugging symbols

INSTALL_SCRIPT

    binaries that cannot be stripped

INSTALL_GAME

    game binaries

INSTALL_LIB

    shared and static libraries

INSTALL_DATA

    data files

INSTALL_GAME_DATA

    data files for games

INSTALL_MAN

    man pages

Some other variables are:

INSTALLATION_DIRS

    A list of directories relative to PREFIX that are created by pkgsrc at the
    beginning of the install phase. The package is supposed to create all
    needed directories itself before installing files to it and list all other
    directories here.

In the rare cases that a package shouldn't install anything, set NO_INSTALL to
"yes". This is mostly relevant for packages in the regress category.

17.15. The package phase

Once the install stage has completed, a binary package of the installed files
can be built. These binary packages can be used for quick installation without
previous compilation, e.g. by the make bin-install or by using pkg_add.

By default, the binary packages are created in ${PACKAGES}/All and symlinks are
created in ${PACKAGES}/category, one for each category in the CATEGORIES
variable. PACKAGES defaults to pkgsrc/packages.

17.16. Cleaning up

Once you're finished with a package, you can clean the work directory by
running make clean. If you want to clean the work directories of all
dependencies too, use make clean-depends.

17.17. Other helpful targets

pre/post-*

    For any of the main targets described in the previous section, two
    auxiliary targets exist with "pre-" and "post-" used as a prefix for the
    main target's name. These targets are invoked before and after the main
    target is called, allowing extra configuration or installation steps be
    performed from a package's Makefile, for example, which a program's
    configure script or install target omitted.

do-*

    Should one of the main targets do the wrong thing, and should there be no
    variable to fix this, you can redefine it with the do-* target. (Note that
    redefining the target itself instead of the do-* target is a bad idea, as
    the pre-* and post-* targets won't be called anymore, etc.) You will not
    usually need to do this.

reinstall

    If you did a make install and you noticed some file was not installed
    properly, you can repeat the installation with this target, which will
    ignore the "already installed" flag.

    This is the default value of DEPENDS_TARGET except in the case of make
    update and make package, where the defaults are "package" and "update",
    respectively.

deinstall

    This target does a pkg_delete(1) in the current directory, effectively
    de-installing the package. The following variables can be used to tune the
    behaviour:

    PKG_VERBOSE

        Add a "-v" to the pkg_delete(1) command.

    DEINSTALLDEPENDS

        Remove all packages that require (depend on) the given package. This
        can be used to remove any packages that may have been pulled in by a
        given package, e.g. if make deinstall DEINSTALLDEPENDS=1 is done in
        pkgsrc/x11/kde, this is likely to remove whole KDE. Works by adding "-R
        " to the pkg_delete(1) command line.

bin-install

    Install a binary package from local disk and via FTP from a list of sites
    (see the BINPKG_SITES variable), and do a make package if no binary package
    is available anywhere. The arguments given to pkg_add can be set via
    BIN_INSTALL_FLAGS e.g., to do verbose operation, etc.

update

    This target causes the current package to be updated to the latest version.
    The package and all depending packages first get de-installed, then current
    versions of the corresponding packages get compiled and installed. This is
    similar to manually noting which packages are currently installed, then
    performing a series of make deinstall and make install (or whatever
    UPDATE_TARGET is set to) for these packages.

    You can use the "update" target to resume package updating in case a
    previous make update was interrupted for some reason. However, in this
    case, make sure you don't call make clean or otherwise remove the list of
    dependent packages in WRKDIR. Otherwise, you lose the ability to
    automatically update the current package along with the dependent packages
    you have installed.

    Resuming an interrupted make update will only work as long as the package
    tree remains unchanged. If the source code for one of the packages to be
    updated has been changed, resuming make update will most certainly fail!

    The following variables can be used either on the command line or in
    mk.conf to alter the behaviour of make update:

    UPDATE_TARGET

        Install target to recursively use for the updated package and the
        dependent packages. Defaults to DEPENDS_TARGET if set, "install"
        otherwise for make update. Other good targets are "package" or "
        bin-install". Do not set this to "update" or you will get stuck in an
        endless loop!

    NOCLEAN

        Don't clean up after updating. Useful if you want to leave the work
        sources of the updated packages around for inspection or other
        purposes. Be sure you eventually clean up the source tree (see the "
        clean-update" target below) or you may run into troubles with old
        source code still lying around on your next make or make update.

    REINSTALL

        Deinstall each package before installing (making DEPENDS_TARGET). This
        may be necessary if the "clean-update" target (see below) was called
        after interrupting a running make update.

    DEPENDS_TARGET

        Allows you to disable recursion and hardcode the target for packages.
        The default is "update" for the update target, facilitating a recursive
        update of prerequisite packages. Only set DEPENDS_TARGET if you want to
        disable recursive updates. Use UPDATE_TARGET instead to just set a
        specific target for each package to be installed during make update
        (see above).

clean-update

    Clean the source tree for all packages that would get updated if make
    update was called from the current directory. This target should not be
    used if the current package (or any of its depending packages) have already
    been de-installed (e.g., after calling make update) or you may lose some
    packages you intended to update. As a rule of thumb: only use this target
    before the first time you run make update and only if you have a dirty
    package tree (e.g., if you used NOCLEAN).

    If you are unsure about whether your tree is clean, you can either perform
    a make clean at the top of the tree, or use the following sequence of
    commands from the directory of the package you want to update (before
    running make update for the first time, otherwise you lose all the packages
    you wanted to update!):

    # make clean-update
    # make clean CLEANDEPENDS=YES
    # make update


    The following variables can be used either on the command line or in
    mk.conf to alter the behaviour of make clean-update:

    CLEAR_DIRLIST

        After make clean, do not reconstruct the list of directories to update
        for this package. Only use this if make update successfully installed
        all packages you wanted to update. Normally, this is done automatically
        on make update, but may have been suppressed by the NOCLEAN variable
        (see above).

replace

    Update the installation of the current package. This differs from update in
    that it does not replace dependent packages. You will need to install
    pkgtools/pkg_tarup for this target to work.

    Be careful when using this target! There are no guarantees that dependent
    packages will still work, in particular they will most certainly break if
    you make replace a library package whose shared library major version
    changed between your installed version and the new one. For this reason,
    this target is not officially supported and only recommended for advanced
    users.

info

    This target invokes pkg_info(1) for the current package. You can use this
    to check which version of a package is installed.

index

    This is a top-level command, i.e. it should be used in the pkgsrc
    directory. It creates a database of all packages in the local pkgsrc tree,
    including dependencies, comment, maintainer, and some other useful
    information. Individual entries are created by running make describe in the
    packages' directories. This index file is saved as pkgsrc/INDEX. It can be
    displayed in verbose format by running make print-index. You can search in
    it with make search key=something. You can extract a list of all packages
    that depend on a particular one by running make show-deps PKG=somepackage.

    Running this command takes a very long time, some hours even on fast
    machines!

readme

    This target generates a README.html file, which can be viewed using a
    browser such as www/firefox or www/links. The generated files contain
    references to any packages which are in the PACKAGES directory on the local
    host. The generated files can be made to refer to URLs based on
    FTP_PKG_URL_HOST and FTP_PKG_URL_DIR. For example, if I wanted to generate
    README.html files which pointed to binary packages on the local machine, in
    the directory /usr/packages, set FTP_PKG_URL_HOST=file://localhost and
    FTP_PKG_URL_DIR=/usr/packages. The ${PACKAGES} directory and its
    subdirectories will be searched for all the binary packages.

    The target can be run at the toplevel or in category directories, in which
    case it descends recursively.

readme-all

    This is a top-level command, run it in pkgsrc. Use this target to create a
    file README-all.html which contains a list of all packages currently
    available in the NetBSD Packages Collection, together with the category
    they belong to and a short description. This file is compiled from the
    pkgsrc/*/README.html files, so be sure to run this after a make readme.

cdrom-readme

    This is very much the same as the "readme" target (see above), but is to be
    used when generating a pkgsrc tree to be written to a CD-ROM. This target
    also produces README.html files, and can be made to refer to URLs based on
    CDROM_PKG_URL_HOST and CDROM_PKG_URL_DIR.

show-distfiles

    This target shows which distfiles and patchfiles are needed to build the
    package (ALLFILES, which contains all DISTFILES and PATCHFILES, but not
    patches/*).

show-downlevel

    This target shows nothing if the package is not installed. If a version of
    this package is installed, but is not the version provided in this version
    of pkgsrc, then a warning message is displayed. This target can be used to
    show which of your installed packages are downlevel, and so the old
    versions can be deleted, and the current ones added.

show-pkgsrc-dir

    This target shows the directory in the pkgsrc hierarchy from which the
    package can be built and installed. This may not be the same directory as
    the one from which the package was installed. This target is intended to be
    used by people who may wish to upgrade many packages on a single host, and
    can be invoked from the top-level pkgsrc Makefile by using the "
    show-host-specific-pkgs" target.

show-installed-depends

    This target shows which installed packages match the current package's
    DEPENDS. Useful if out of date dependencies are causing build problems.

check-shlibs

    After a package is installed, check all its binaries and (on ELF platforms)
    shared libraries to see if they find the shared libs they need. Run by
    default if PKG_DEVELOPER is set in mk.conf.

print-PLIST

    After a "make install" from a new or upgraded pkg, this prints out an
    attempt to generate a new PLIST from a find -newer work/.extract_done. An
    attempt is made to care for shared libs etc., but it is strongly
    recommended to review the result before putting it into PLIST. On upgrades,
    it's useful to diff the output of this command against an already existing
    PLIST file.

    If the package installs files via tar(1) or other methods that don't update
    file access times, be sure to add these files manually to your PLIST, as
    the "find -newer" command used by this target won't catch them!

    See Section 13.3, "Tweaking output of make print-PLIST" for more
    information on this target.

bulk-package

    Used to do bulk builds. If an appropriate binary package already exists, no
    action is taken. If not, this target will compile, install and package it
    (and its depends, if PKG_DEPENDS is set properly. See Section 7.3.1,
    "Configuration"). After creating the binary package, the sources, the
    just-installed package and its required packages are removed, preserving
    free disk space.

    Beware that this target may deinstall all packages installed on a system!

bulk-install

    Used during bulk-installs to install required packages. If an up-to-date
    binary package is available, it will be installed via pkg_add(1). If not,
    make bulk-package will be executed, but the installed binary won't be
    removed.

    A binary package is considered "up-to-date" to be installed via pkg_add(1)
    if:

      * None of the package's files (Makefile, ...) were modified since it was
        built.

      * None of the package's required (binary) packages were modified since it
        was built.

    Beware that this target may deinstall all packages installed on a system!

Chapter 18. Tools needed for building or running

Table of Contents

18.1. Tools for pkgsrc builds
18.2. Tools needed by packages
18.3. Tools provided by platforms
18.4. Questions regarding the tools

The USE_TOOLS definition is used both internally by pkgsrc and also for
individual packages to define what commands are needed for building a package
(like BUILD_DEPENDS) or for later run-time of an installed packaged (such as
DEPENDS). If the native system provides an adequate tool, then in many cases, a
pkgsrc package will not be used.

When building a package, the replacement tools are made available in a
directory (as symlinks or wrapper scripts) that is early in the executable
search path. Just like the buildlink system, this helps with consistent builds.

A tool may be needed to help build a specific package. For example, perl, GNU
make (gmake) or yacc may be needed.

Also a tool may be needed, for example, because the native system's supplied
tool may be inefficient for building a package with pkgsrc. For example, a
package may need GNU awk, bison (instead of yacc) or a better sed.

The tools used by a package can be listed by running make show-tools.

18.1. Tools for pkgsrc builds

The default set of tools used by pkgsrc is defined in bsd.pkg.mk. This includes
standard Unix tools, such as: cat, awk, chmod, test, and so on. These can be
seen by running: make show-var VARNAME=USE_TOOLS.

If a package needs a specific program to build then the USE_TOOLS variable can
be used to define the tools needed.

18.2. Tools needed by packages

In the following examples, the :run means that it is needed at run-time (and
becomes a DEPENDS). The default is a build dependency which can be set with
:build. (So in this example, it is the same as gmake:build and
pkg-config:build.)

USE_TOOLS+= gmake perl:run pkg-config

When using the tools framework, a TOOLS_PATH.foo variable is defined which
contains the full path to the appropriate tool. For example, TOOLS_PATH.bash
could be "/bin/bash" on Linux systems.

If you always need a pkgsrc version of the tool at run-time, then just use
DEPENDS instead.

18.3. Tools provided by platforms

When improving or porting pkgsrc to a new platform, have a look at (or create)
the corresponding platform specific make file fragment under pkgsrc/mk/tools/
tools.${OPSYS}.mk which defines the name of the common tools. For example:

.if exists(/usr/bin/bzcat)
TOOLS_PLATFORM.bzcat?= /usr/bin/bzcat
.elif exists(/usr/bin/bzip2)
TOOLS_PLATFORM.bzcat?= /usr/bin/bzip2 -cd
.endif

TOOLS_PLATFORM.true?= true # shell builtin

18.4. Questions regarding the tools

18.4.1. How do I add a new tool?
18.4.2. How do I get a list of all available tools?
18.4.3. How can I get a list of all the tools that a package is using while
    being built? I want to know whether it uses sed or not.

18.4.1. How do I add a new tool?

        TODO

18.4.2. How do I get a list of all available tools?

        TODO

18.4.3. How can I get a list of all the tools that a package is using while
        being built? I want to know whether it uses sed or not.

        Currently, you can't. (TODO: But I want to be able to do it.)

Chapter 19. Making your package work

Table of Contents

19.1. General operation

    19.1.1. Portability of packages
    19.1.2. How to pull in user-settable variables from mk.conf
    19.1.3. User interaction
    19.1.4. Handling licenses
    19.1.5. Restricted packages
    19.1.6. Handling dependencies
    19.1.7. Handling conflicts with other packages
    19.1.8. Packages that cannot or should not be built
    19.1.9. Packages which should not be deleted, once installed
    19.1.10. Handling packages with security problems
    19.1.11. How to handle incrementing versions when fixing an existing
        package
    19.1.12. Substituting variable text in the package files (the SUBST
        framework)

19.2. Fixing problems in the fetch phase

    19.2.1. Packages whose distfiles aren't available for plain downloading
    19.2.2. How to handle modified distfiles with the 'old' name

19.3. Fixing problems in the configure phase

    19.3.1. Shared libraries - libtool
    19.3.2. Using libtool on GNU packages that already support libtool
    19.3.3. GNU Autoconf/Automake

19.4. Programming languages

    19.4.1. C, C++, and Fortran
    19.4.2. Java
    19.4.3. Packages containing perl scripts
    19.4.4. Other programming languages

19.5. Fixing problems in the build phase

    19.5.1. Compiling C and C++ code conditionally
    19.5.2. How to handle compiler bugs
    19.5.3. Undefined reference to "..."
    19.5.4. Running out of memory

19.6. Fixing problems in the install phase

    19.6.1. Creating needed directories
    19.6.2. Where to install documentation
    19.6.3. Installing highscore files
    19.6.4. Adding DESTDIR support to packages
    19.6.5. Packages with hardcoded paths to other interpreters
    19.6.6. Packages installing perl modules
    19.6.7. Packages installing info files
    19.6.8. Packages installing man pages
    19.6.9. Packages installing GConf data files
    19.6.10. Packages installing scrollkeeper/rarian data files
    19.6.11. Packages installing X11 fonts
    19.6.12. Packages installing GTK2 modules
    19.6.13. Packages installing SGML or XML data
    19.6.14. Packages installing extensions to the MIME database
    19.6.15. Packages using intltool
    19.6.16. Packages installing startup scripts
    19.6.17. Packages installing TeX modules
    19.6.18. Packages supporting running binaries in emulation
    19.6.19. Packages installing hicolor theme icons
    19.6.20. Packages installing desktop files

19.7. Marking packages as having problems

19.1. General operation

19.1.1. Portability of packages

One appealing feature of pkgsrc is that it runs on many different platforms. As
a result, it is important to ensure, where possible, that packages in pkgsrc
are portable. This chapter mentions some particular details you should pay
attention to while working on pkgsrc.

19.1.2. How to pull in user-settable variables from mk.conf

The pkgsrc user can configure pkgsrc by overriding several variables in the
file pointed to by MAKECONF, which is mk.conf by default. When you want to use
those variables in the preprocessor directives of make(1) (for example .if or
.for), you need to include the file ../../mk/bsd.prefs.mk before, which in turn
loads the user preferences.

But note that some variables may not be completely defined after ../../mk/
bsd.prefs.mk has been included, as they may contain references to variables
that are not yet defined. In shell commands this is no problem, since variables
are actually macros, which are only expanded when they are used. But in the
preprocessor directives mentioned above and in dependency lines (of the form
target: dependencies) the variables are expanded at load time.

Note

Currently there is no exhaustive list of all variables that tells you whether
they can be used at load time or only at run time, but it is in preparation.

19.1.3. User interaction

Occasionally, packages require interaction from the user, and this can be in a
number of ways:

  * When fetching the distfiles, some packages require user interaction such as
    entering username/password or accepting a license on a web page.

  * When extracting the distfiles, some packages may ask for passwords.

  * help to configure the package before it is built

  * help during the build process

  * help during the installation of a package

The INTERACTIVE_STAGE definition is provided to notify the pkgsrc mechanism of
an interactive stage which will be needed, and this should be set in the
package's Makefile, e.g.:

INTERACTIVE_STAGE= build


Multiple interactive stages can be specified:

INTERACTIVE_STAGE= configure install


The user can then decide to skip this package by setting the BATCH variable.

19.1.4. Handling licenses

Authors of software can choose the licence under which software can be copied.
This is due to copyright law, and reasons for license choices are outside the
scope of pkgsrc. The pkgsrc system recognizes that there are a number of
licenses which some users may find objectionable or difficult or impossible to
comply with. The Free Software Foundation has declared some licenses "Free",
and the Open Source Initiative has a definition of "Open Source". The pkgsrc
system, as a policy choice, does not label packages which have licenses that
are Free or Open Source. However, packages without a license meeting either of
those tests are labeled with a license tag denoting the license. Note that a
package with no license to copy trivially does not meet either the Free or Open
Source test.

For packages which are not Free or Open Source, pkgsrc will not build the
package unless the user has indicated to pkgsrc that packages with that
particular license may be built. Note that this documentation avoids the term
"accepted the license". The pkgsrc system is merely providing a mechanism to
avoid accidentally building a package with a non-free license; judgement and
responsibility remain with the user. (Installation of binary packages are not
currently subject to this mechanism; this is a bug.)

One might want to only install packages with a BSD license, or the GPL, and not
the other. The free licenses are added to the default ACCEPTABLE_LICENSES
variable. The user can override the default by setting the ACCEPTABLE_LICENSES
variable with "=" instead of "+=". The licenses accepted by default are:

        public-domain unlicense
        gnu-fdl-v1.1 gnu-fdl-v1.2 gnu-fdl-v1.3
        gnu-gpl-v1
        gnu-gpl-v2 gnu-lgpl-v2 gnu-lgpl-v2.1
        gnu-gpl-v3 gnu-lgpl-v3
        original-bsd modified-bsd 2-clause-bsd
        x11 mit miros
        apache-1.1 apache-2.0
        artistic artistic-2.0
        cddl-1.0
        cpl-1.0
        open-font-license
        mpl-1.0 mpl-1.1 mpl-2.0
        php png-license
        postgresql-license
        zlib
        zpl
        python-software-foundation
        ipafont
        ibm-public-license-1.0
        isc
        boost-license
        mplusfont
        cc-by-sa-v3.0
        lppl-1.3c
        lucent
        epl-v1.0
        info-zip


The license tag mechanism is intended to address copyright-related issues
surrounding building, installing and using a package, and not to address
redistribution issues (see RESTRICTED and NO_SRC_ON_FTP, etc.). Packages with
redistribution restrictions should set these tags.

Denoting that a package may be copied according to a particular license is done
by placing the license in pkgsrc/licenses and setting the LICENSE variable to a
string identifying the license, e.g. in graphics/xv:

LICENSE= xv-license


When trying to build, the user will get a notice that the package is covered by
a license which has not been placed in the ACCEPTABLE_LICENSES variable:

% make
===> xv-3.10anb9 has an unacceptable license: xv-license.
===> To view the license, enter "/usr/bin/make show-license".
===> To indicate acceptance, add this line to your /etc/mk.conf:
===> ACCEPTABLE_LICENSES+=xv-license
*** Error code 1


The license can be viewed with make show-license, and if the user so chooses,
the line printed above can be added to mk.conf to convey to pkgsrc that it
should not in the future fail because of that license:

ACCEPTABLE_LICENSES+=xv-license


When adding a package with a new license, the license text should be added to
pkgsrc/licenses for displaying. A list of known licenses can be seen in this
directory.

When the license changes (in a way other than formatting), please make sure
that the new license has a different name (e.g., append the version number if
it exists, or the date). Just because a user told pkgsrc to build programs
under a previous version of a license does not mean that pkgsrc should build
programs under the new licenses. The higher-level point is that pkgsrc does not
evaluate licenses for reasonableness; the only test is a mechanistic test of
whether a particular text has been approved by either of two bodies.

The use of LICENSE=shareware, LICENSE=no-commercial-use, and similar language
is deprecated because it does not crisply refer to a particular license text.
Another problem with such usage is that it does not enable a user to tell
pkgsrc to proceed for a single package without also telling pkgsrc to proceed
for all packages with that tag.

19.1.5. Restricted packages

Some licenses restrict how software may be re-distributed. Because a license
tag is required unless the package is Free or Open Source, all packages with
restrictions should have license tags. By declaring the restrictions, package
tools can automatically refrain from e.g. placing binary packages on FTP sites.

There are four restrictions that may be encoded, which are the cross product of
sources (distfiles) and binaries not being placed on FTP sites and CD-ROMs.
Because this is rarely the exact language in any license, and because non-Free
licenses tend to be different from each other, pkgsrc adopts a definition of
FTP and CD-ROM. Pkgsrc uses "FTP" to mean that the source or binary file should
not be made available over the Internet at no charge. Pkgsrc uses "CD-ROM" to
mean that the source or binary may not be made available on some kind of media,
together with other source and binary packages, and which is sold for a
distribution charge.

In order to encode these restrictions, the package system defines five make
variables that can be set to note these restrictions:

  * RESTRICTED

    This variable should be set whenever a restriction exists (regardless of
    its kind). Set this variable to a string containing the reason for the
    restriction. It should be understood that those wanting to understand the
    restriction will have to read the license, and perhaps seek advice of
    counsel.

  * NO_BIN_ON_CDROM

    Binaries may not be placed on CD-ROM containing other binary packages, for
    which a distribution charge may be made. In this case, set this variable to
    ${RESTRICTED}.

  * NO_BIN_ON_FTP

    Binaries may not made available on the Internet without charge. In this
    case, set this variable to ${RESTRICTED}. If this variable is set, binary
    packages will not be included on ftp.NetBSD.org.

  * NO_SRC_ON_CDROM

    Distfiles may not be placed on CD-ROM, together with other distfiles, for
    which a fee may be charged. In this case, set this variable to $
    {RESTRICTED}.

  * NO_SRC_ON_FTP

    Distfiles may not made available via FTP at no charge. In this case, set
    this variable to ${RESTRICTED}. If this variable is set, the distfile(s)
    will not be mirrored on ftp.NetBSD.org.

Please note that packages will to be removed from pkgsrc when the distfiles are
not distributable and cannot be obtained for a period of one full quarter
branch. Packages with manual / interactive fetch must have a maintainer and it
is his/her responsibility to ensure this.

19.1.6. Handling dependencies

Your package may depend on some other package being present - and there are
various ways of expressing this dependency. pkgsrc supports the BUILD_DEPENDS
and DEPENDS definitions, the USE_TOOLS definition, as well as dependencies via
buildlink3.mk, which is the preferred way to handle dependencies, and which
uses the variables named above. See Chapter 14, Buildlink methodology for more
information.

The basic difference between the two variables is as follows: The DEPENDS
definition registers that pre-requisite in the binary package so it will be
pulled in when the binary package is later installed, whilst the BUILD_DEPENDS
definition does not, marking a dependency that is only needed for building the
package.

This means that if you only need a package present whilst you are building, it
should be noted as a BUILD_DEPENDS.

The format for a BUILD_DEPENDS and a DEPENDS definition is:

<pre-req-package-name>:../../<category>/<pre-req-package>


Please note that the "pre-req-package-name" may include any of the wildcard
version numbers recognized by pkg_info(1).

 1. If your package needs another package's binaries or libraries to build or
    run, and if that package has a buildlink3.mk file available, use it:

    .include "../../graphics/jpeg/buildlink3.mk"


 2. If your package needs binaries from another package to build, use the
    BUILD_DEPENDS definition:

    BUILD_DEPENDS+= scons-[0-9]*:../../devel/scons


 3. If your package needs a library with which to link and there is no
    buildlink3.mk file available, create one. Using DEPENDS won't be sufficient
    because the include files and libraries will be hidden from the compiler.

 4. If your package needs some executable to be able to run correctly and if
    there's no buildlink3.mk file, this is specified using the DEPENDS
    variable. The print/lyx package needs to be able to execute the latex
    binary from the teTeX package when it runs, and that is specified:

    DEPENDS+= teTeX-[0-9]*:../../print/teTeX


 5. You can use wildcards in package dependencies. Note that such wildcard
    dependencies are retained when creating binary packages. The dependency is
    checked when installing the binary package and any package which matches
    the pattern will be used. Wildcard dependencies should be used with care.

    The "-[0-9]*" should be used instead of "-*" to avoid potentially ambiguous
    matches such as "tk-postgresql" matching a "tk-*" DEPENDS.

    Wildcards can also be used to specify that a package will only build
    against a certain minimum version of a pre-requisite:

    DEPENDS+= ImageMagick>=6.0:../../graphics/ImageMagick


    This means that the package will build using version 6.0 of ImageMagick or
    newer. Such a dependency may be warranted if, for example, the command line
    options of an executable have changed.

    If you need to depend on minimum versions of libraries, see the buildlink
    section of the pkgsrc guide.

    For security fixes, please update the package vulnerabilities file. See
    Section 19.1.10, "Handling packages with security problems" for more
    information.

If your package needs files from another package to build, add the relevant
distribution files to DISTFILES, so they will be extracted automatically. See
the print/ghostscript package for an example. (It relies on the jpeg sources
being present in source form during the build.)

19.1.7. Handling conflicts with other packages

Your package may conflict with other packages a user might already have
installed on his system, e.g. if your package installs the same set of files as
another package in the pkgsrc tree.

In this case you can set CONFLICTS to a space-separated list of packages
(including version string) your package conflicts with.

For example, x11/Xaw3d and x11/Xaw-Xpm install the same shared library, thus
you set in pkgsrc/x11/Xaw3d/Makefile:

CONFLICTS= Xaw-Xpm-[0-9]*


and in pkgsrc/x11/Xaw-Xpm/Makefile:

CONFLICTS= Xaw3d-[0-9]*


Packages will automatically conflict with other packages with the name prefix
and a different version string. "Xaw3d-1.5" e.g. will automatically conflict
with the older version "Xaw3d-1.3".

19.1.8. Packages that cannot or should not be built

There are several reasons why a package might be instructed to not build under
certain circumstances. If the package builds and runs on most platforms, the
exceptions should be noted with NOT_FOR_PLATFORM. If the package builds and
runs on a small handful of platforms, set ONLY_FOR_PLATFORM instead. Both
ONLY_FOR_PLATFORM and NOT_FOR_PLATFORM are OS triples (OS-version-platform)
that can use glob-style wildcards.

Some packages are tightly bound to a specific version of an operating system,
e.g. LKMs or sysutils/lsof. Such binary packages are not backwards compatible
with other versions of the OS, and should be uploaded to a version specific
directory on the FTP server. Mark these packages by setting OSVERSION_SPECIFIC
to "yes". This variable is not currently used by any of the package system
internals, but may be used in the future.

If the package should be skipped (for example, because it provides
functionality already provided by the system), set PKG_SKIP_REASON to a
descriptive message. If the package should fail because some preconditions are
not met, set PKG_FAIL_REASON to a descriptive message.

19.1.9. Packages which should not be deleted, once installed

To ensure that a package may not be deleted, once it has been installed, the
PKG_PRESERVE definition should be set in the package Makefile. This will be
carried into any binary package that is made from this pkgsrc entry. A "
preserved" package will not be deleted using pkg_delete(1) unless the "-f"
option is used.

19.1.10. Handling packages with security problems

When a vulnerability is found, this should be noted in localsrc/security/
advisories/pkg-vulnerabilities, and after committing that file, ask
pkgsrc-security@NetBSD.org to update the file on ftp.NetBSD.org.

After fixing the vulnerability by a patch, its PKGREVISION should be increased
(this is of course not necessary if the problem is fixed by using a newer
release of the software), and the pattern in the pkg-vulnerabilities file must
be updated.

Also, if the fix should be applied to the stable pkgsrc branch, be sure to
submit a pullup request!

Binary packages already on ftp.NetBSD.org will be handled semi-automatically by
a weekly cron job.

19.1.11. How to handle incrementing versions when fixing an existing package

When making fixes to an existing package it can be useful to change the version
number in PKGNAME. To avoid conflicting with future versions by the original
author, a "nb1", "nb2", ... suffix can be used on package versions by setting
PKGREVISION=1 (2, ...). The "nb" is treated like a "." by the package tools.
e.g.

DISTNAME= foo-17.42
PKGREVISION= 9


will result in a PKGNAME of "foo-17.42nb9". If you want to use the original
value of PKGNAME without the "nbX" suffix, e.g. for setting DIST_SUBDIR, use
PKGNAME_NOREV.

When a new release of the package is released, the PKGREVISION should be
removed, e.g. on a new minor release of the above package, things should be
like:

DISTNAME= foo-17.43


PKGREVISION should be incremented for any non-trivial change in the resulting
binary package. Without a PKGREVISION bump, someone with the previous version
installed has no way of knowing that their package is out of date. Thus,
changes without increasing PKGREVISION are essentially labeled "this is so
trivial that no reasonable person would want to upgrade", and this is the rough
test for when increasing PKGREVISION is appropriate. Examples of changes that
do not merit increasing PKGREVISION are:

  * Changing HOMEPAGE, MAINTAINER, OWNER, or comments in Makefile.

  * Changing build variables if the resulting binary package is the same.

  * Changing DESCR.

  * Adding PKG_OPTIONS if the default options don't change.

Examples of changes that do merit an increase to PKGREVISION include:

  * Security fixes

  * Changes or additions to a patch file

  * Changes to the PLIST

  * A dependency is changed or renamed.

PKGREVISION must also be incremented when dependencies have ABI changes.

19.1.12. Substituting variable text in the package files (the SUBST framework)

When you want to replace the same text in multiple files or when the
replacement text varies, patches alone cannot help. This is where the SUBST
framework comes in. It provides an easy-to-use interface for replacing text in
files. Example:

SUBST_CLASSES+= fix-paths
SUBST_STAGE.fix-paths= pre-configure
SUBST_MESSAGE.fix-paths= Fixing absolute paths.
SUBST_FILES.fix-paths= src/*.c
SUBST_FILES.fix-paths+= scripts/*.sh
SUBST_SED.fix-paths= -e 's,"/usr/local,"${PREFIX},g'
SUBST_SED.fix-paths+= -e 's,"/var/log,"${VARBASE}/log,g'


SUBST_CLASSES is a list of identifiers that are used to identify the different
SUBST blocks that are defined. The SUBST framework is heavily used by pkgsrc,
so it is important to always use the += operator with this variable. Otherwise
some substitutions may be skipped.

The remaining variables of each SUBST block are parameterized with the
identifier from the first line (fix-paths in this case.) They can be seen as
parameters to a function call.

SUBST_STAGE.* specifies the stage at which the replacement will take place. All
combinations of pre-, do- and post- together with a phase name are possible,
though only few are actually used. Most commonly used are post-patch and
pre-configure. Of these two, pre-configure should be preferred because then it
is possible to run bmake patch and have the state after applying the patches
but before making any other changes. This is especially useful when you are
debugging a package in order to create new patches for it. Similarly,
post-build is preferred over pre-install, because the install phase should
generally be kept as simple as possible. When you use post-build, you have the
same files in the working directory that will be installed later, so you can
check if the substitution has succeeded.

SUBST_MESSAGE.* is an optional text that is printed just before the
substitution is done.

SUBST_FILES.* is the list of shell globbing patterns that specifies the files
in which the substitution will take place. The patterns are interpreted
relatively to the WRKSRC directory.

SUBST_SED.* is a list of arguments to sed(1) that specify the actual
substitution. Every sed command should be prefixed with -e, so that all SUBST
blocks look uniform.

There are some more variables, but they are so seldomly used that they are only
documented in the mk/subst.mk file.

19.2. Fixing problems in the fetch phase

19.2.1. Packages whose distfiles aren't available for plain downloading

If you need to download from a dynamic URL you can set DYNAMIC_MASTER_SITES and
a make fetch will call files/getsite.sh with the name of each file to download
as an argument, expecting it to output the URL of the directory from which to
download it. graphics/ns-cult3d is an example of this usage.

If the download can't be automated, because the user must submit personal
information to apply for a password, or must pay for the source, or whatever,
you can set FETCH_MESSAGE to a list of lines that are displayed to the user
before aborting the build. Example:

FETCH_MESSAGE= "Please download the files"
FETCH_MESSAGE+= " "${DISTFILES:Q}
FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"."


19.2.2. How to handle modified distfiles with the 'old' name

Sometimes authors of a software package make some modifications after the
software was released, and they put up a new distfile without changing the
package's version number. If a package is already in pkgsrc at that time, the
checksum will no longer match. The contents of the new distfile should be
compared against the old one before changing anything, to make sure the
distfile was really updated on purpose, and that no trojan horse or so crept
in. Please mention that the distfiles were compared and what was found in your
commit message. Then, the correct way to work around this is to set DIST_SUBDIR
to a unique directory name, usually based on PKGNAME_NOREV. All DISTFILES and
PATCHFILES for this package will be put in that subdirectory of the local
distfiles directory. (See Section 19.1.11, "How to handle incrementing versions
when fixing an existing package" for more details.) In case this happens more
often, PKGNAME can be used (thus including the nbX suffix) or a date stamp can
be appended, like ${PKGNAME_NOREV}-YYYYMMDD. Do not forget regenerating the
distinfo file after that, since it contains the DIST_SUBDIR path in the
filenames. Also increase the PKGREVISION if the installed package is different.
Furthermore, a mail to the package's authors seems appropriate telling them
that changing distfiles after releases without changing the file names is not
good practice.

19.3. Fixing problems in the configure phase

19.3.1. Shared libraries - libtool

pkgsrc supports many different machines, with different object formats like
a.out and ELF, and varying abilities to do shared library and dynamic loading
at all. To accompany this, varying commands and options have to be passed to
the compiler, linker, etc. to get the Right Thing, which can be pretty annoying
especially if you don't have all the machines at your hand to test things. The
devel/libtool pkg can help here, as it just "knows" how to build both static
and dynamic libraries from a set of source files, thus being
platform-independent.

Here's how to use libtool in a package in seven simple steps:

 1. Add USE_LIBTOOL=yes to the package Makefile.

 2. For library objects, use "${LIBTOOL} --mode=compile ${CC}" in place of "$
    {CC}". You could even add it to the definition of CC, if only libraries are
    being built in a given Makefile. This one command will build both PIC and
    non-PIC library objects, so you need not have separate shared and
    non-shared library rules.

 3. For the linking of the library, remove any "ar", "ranlib", and "ld
    -Bshareable" commands, and instead use:

    ${LIBTOOL} --mode=link \
        ${CC} -o ${.TARGET:.a=.la} \
            ${OBJS:.o=.lo} \
            -rpath ${PREFIX}/lib \
            -version-info major:minor


    Note that the library is changed to have a .la extension, and the objects
    are changed to have a .lo extension. Change OBJS as necessary. This
    automatically creates all of the .a, .so.major.minor, and ELF symlinks (if
    necessary) in the build directory. Be sure to include "-version-info",
    especially when major and minor are zero, as libtool will otherwise strip
    off the shared library version.

    From the libtool manual:

    So, libtool library versions are described by three integers:

    CURRENT
    The most recent interface number that this library implements.

    REVISION
    The implementation number of the CURRENT interface.

    AGE
    The difference between the newest and oldest interfaces that
    this library implements. In other words, the library implements
    all the interface numbers in the range from number `CURRENT -
    AGE' to `CURRENT'.

    If two libraries have identical CURRENT and AGE numbers, then the
    dynamic linker chooses the library with the greater REVISION number.


    The "-release" option will produce different results for a.out and ELF
    (excluding symlinks) in only one case. An ELF library of the form "
    libfoo-release.so.x.y" will have a symlink of "libfoo.so.x.y" on an a.out
    platform. This is handled automatically.

    The "-rpath argument" is the install directory of the library being built.

    In the PLIST, include only the .la file, the other files will be added
    automatically.

 4. When linking shared object (.so) files, i.e. files that are loaded via
    dlopen(3), NOT shared libraries, use "-module -avoid-version" to prevent
    them getting version tacked on.

    The PLIST file gets the foo.so entry.

 5. When linking programs that depend on these libraries before they are
    installed, preface the cc(1) or ld(1) line with "${LIBTOOL} --mode=link",
    and it will find the correct libraries (static or shared), but please be
    aware that libtool will not allow you to specify a relative path in -L
    (such as "-L../somelib"), because it expects you to change that argument to
    be the .la file. e.g.

    ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib


    should be changed to:

    ${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la


    and it will do the right thing with the libraries.

 6. When installing libraries, preface the install(1) or cp(1) command with "$
    {LIBTOOL} --mode=install", and change the library name to .la. e.g.

    ${LIBTOOL} --mode=install ${BSD_INSTALL_LIB} ${SOMELIB:.a=.la} ${PREFIX}/lib


    This will install the static .a, shared library, any needed symlinks, and
    run ldconfig(8).

 7. In your PLIST, include only the .la file (this is a change from previous
    behaviour).

19.3.2. Using libtool on GNU packages that already support libtool

Add USE_LIBTOOL=yes to the package Makefile. This will override the package's
own libtool in most cases. For older libtool using packages, libtool is made by
ltconfig script during the do-configure step; you can check the libtool script
location by doing make configure; find work*/ -name libtool.

LIBTOOL_OVERRIDE specifies which libtool scripts, relative to WRKSRC, to
override. By default, it is set to "libtool */libtool */*/libtool". If this
does not match the location of the package's libtool script(s), set it as
appropriate.

If you do not need *.a static libraries built and installed, then use
SHLIBTOOL_OVERRIDE instead.

If your package makes use of the platform-independent library for loading
dynamic shared objects, that comes with libtool (libltdl), you should include
devel/libltdl/buildlink3.mk.

Some packages use libtool incorrectly so that the package may not work or build
in some circumstances. Some of the more common errors are:

  * The inclusion of a shared object (-module) as a dependent library in an
    executable or library. This in itself isn't a problem if one of two things
    has been done:

     1. The shared object is named correctly, i.e. libfoo.la, not foo.la

     2. The -dlopen option is used when linking an executable.

  * The use of libltdl without the correct calls to initialisation routines.
    The function lt_dlinit() should be called and the macro
    LTDL_SET_PRELOADED_SYMBOLS included in executables.

19.3.3. GNU Autoconf/Automake

If a package needs GNU autoconf or automake to be executed to regenerate the
configure script and Makefile.in makefile templates, then they should be
executed in a pre-configure target.

For packages that need only autoconf:

AUTOCONF_REQD= 2.50 # if default version is not good enough
USE_TOOLS+= autoconf # use "autoconf213" for autoconf-2.13
...

pre-configure:
        cd ${WRKSRC} && autoconf

...


and for packages that need automake and autoconf:

AUTOMAKE_REQD= 1.7.1 # if default version is not good enough
USE_TOOLS+= automake # use "automake14" for automake-1.4
...

pre-configure:
        set -e; cd ${WRKSRC}; \
        aclocal; autoheader; automake -a --foreign -i; autoconf

...


Packages which use GNU Automake will almost certainly require GNU Make.

There are times when the configure process makes additional changes to the
generated files, which then causes the build process to try to re-execute the
automake sequence. This is prevented by touching various files in the configure
stage. If this causes problems with your package you can set AUTOMAKE_OVERRIDE=
NO in the package Makefile.

19.4. Programming languages

19.4.1. C, C++, and Fortran

Compilers for the C, C++, and Fortran languages comes with the NetBSD base
system. By default, pkgsrc assumes that a package is written in C and will hide
all other compilers (via the wrapper framework, see Chapter 14, Buildlink
methodology).

To declare which language's compiler a package needs, set the USE_LANGUAGES
variable. Allowed values currently are "c", "c++", and "fortran" (and any
combination). The default is "c". Packages using GNU configure scripts, even if
written in C++, usually need a C compiler for the configure phase.

19.4.2. Java

If a program is written in Java, use the Java framework in pkgsrc. The package
must include ../../mk/java-vm.mk. This Makefile fragment provides the following
variables:

  * USE_JAVA defines if a build dependency on the JDK is added. If USE_JAVA is
    set to "run", then there is only a runtime dependency on the JDK. The
    default is "yes", which also adds a build dependency on the JDK.

  * Set USE_JAVA2 to declare that a package needs a Java2 implementation. The
    supported values are "yes", "1.4", and "1.5". "yes" accepts any Java2
    implementation, "1.4" insists on versions 1.4 or above, and "1.5" only
    accepts versions 1.5 or above. This variable is not set by default.

  * PKG_JAVA_HOME is automatically set to the runtime location of the used Java
    implementation dependency. It may be used to set JAVA_HOME to a good value
    if the program needs this variable to be defined.

19.4.3. Packages containing perl scripts

If your package contains interpreted perl scripts, add "perl" to the USE_TOOLS
variable and set REPLACE_PERL to ensure that the proper interpreter path is
set. REPLACE_PERL should contain a list of scripts, relative to WRKSRC, that
you want adjusted. Every occurrence of */bin/perl will be replaced with the
full path to the perl executable.

If a particular version of perl is needed, set the PERL5_REQD variable to the
version number. The default is "5.0".

See Section 19.6.6, "Packages installing perl modules" for information about
handling perl modules.

19.4.4. Other programming languages

Currently, there is no special handling for other languages in pkgsrc. If a
compiler package provides a buildlink3.mk file, include that, otherwise just
add a (build) dependency on the appropriate compiler package.

19.5. Fixing problems in the build phase

The most common failures when building a package are that some platforms do not
provide certain header files, functions or libraries, or they provide the
functions in a library that the original package author didn't know. To work
around this, you can rewrite the source code in most cases so that it does not
use the missing functions or provides a replacement function.

19.5.1. Compiling C and C++ code conditionally

If a package already comes with a GNU configure script, the preferred way to
fix the build failure is to change the configure script, not the code. In the
other cases, you can utilize the C preprocessor, which defines certain macros
depending on the operating system and hardware architecture it compiles for.
These macros can be queried using for example #if defined(__i386). Almost every
operating system, hardware architecture and compiler has its own macro. For
example, if the macros __GNUC__, __i386__ and __NetBSD__ are all defined, you
know that you are using NetBSD on an i386 compatible CPU, and your compiler is
GCC.

The list of the following macros for hardware and operating system depends on
the compiler that is used. For example, if you want to conditionally compile
code on Solaris, don't use __sun__, as the SunPro compiler does not define it.
Use __sun instead.

19.5.1.1. C preprocessor macros to identify the operating system

To distinguish between 4.4 BSD-derived systems and the rest of the world, you
should use the following code.

#include <sys/param.h>
#if (defined(BSD) && BSD >= 199306)
/* BSD-specific code goes here */
#else
/* non-BSD-specific code goes here */
#endif

If this distinction is not fine enough, you can also test for the following
macros.

FreeBSD __FreeBSD__
DragonFly __DragonFly__
Interix __INTERIX
IRIX __sgi (TODO: get a definite source for this)
Linux linux, __linux, __linux__
NetBSD __NetBSD__
OpenBSD __OpenBSD__
Solaris sun, __sun

19.5.1.2. C preprocessor macros to identify the hardware architecture

i386 i386, __i386, __i386__
MIPS __mips
SPARC sparc, __sparc

19.5.1.3. C preprocessor macros to identify the compiler

GCC __GNUC__ (major version), __GNUC_MINOR__
MIPSpro _COMPILER_VERSION (0x741 for MIPSpro 7.41)
SunPro __SUNPRO_C (0x570 for Sun C 5.7)
SunPro C++ __SUNPRO_CC (0x580 for Sun C++ 5.8)

19.5.2. How to handle compiler bugs

Some source files trigger bugs in the compiler, based on combinations of
compiler version and architecture and almost always relation to optimisation
being enabled. Common symptoms are gcc internal errors or never finishing
compiling a file.

Typically, a workaround involves testing the MACHINE_ARCH and compiler version,
disabling optimisation for that combination of file, MACHINE_ARCH and compiler,
and documenting it in pkgsrc/doc/HACKS. See that file for a number of examples.

19.5.3. Undefined reference to "..."

This error message often means that a package did not link to a shared library
it needs. The following functions are known to cause this error message over
and over.

+-----------------------------------------------------+
| Function |Library |Affected platforms|
|-------------------------+--------+------------------|
|accept, bind, co