/usr/share/doc/developers-reference-it/ch06.html is in developers-reference-it 3.4.19.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
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 | <?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Capitolo 6. Buone pratiche per la pacchettizzazione</title>
<link rel="stylesheet" type="text/css" href="developers-reference.css"/>
<meta name="generator" content="DocBook XSL Stylesheets V1.79.1"/>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<link rel="home" href="index.html" title="Debian Developer's Reference"/>
<link rel="up" href="index.html" title="Debian Developer's Reference"/>
<link rel="prev" href="ch05.html" title="Capitolo 5. Gestione dei pacchetti"/>
<link rel="next" href="ch07.html" title="Capitolo 7. Oltre la pacchettizzazione"/>
</head>
<body>
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr>
<th colspan="3" align="center">Capitolo 6. Buone pratiche per la pacchettizzazione</th>
</tr>
<tr>
<td align="left"><a accesskey="p" href="ch05.html"><img src="images/prev.png" alt="Indietro"/></a> </td>
<th width="60%" align="center"> </th>
<td align="right"> <a accesskey="n" href="ch07.html"><img src="images/next.png" alt="Avanti"/></a></td>
</tr>
</table>
<hr/>
</div>
<div class="chapter">
<div class="titlepage">
<div>
<div>
<h1 class="title"><a id="best-pkging-practices"/>Capitolo 6. Buone pratiche per la pacchettizzazione</h1>
</div>
</div>
</div>
<div class="toc">
<p>
<strong>Indice</strong>
</p>
<dl class="toc">
<dt>
<span class="section">
<a href="ch06.html#bpp-debian-rules">6.1. Buone pratiche per <code class="filename">debian/rules</code></a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch06.html#helper-scripts">6.1.1. Script di supporto</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#multiple-patches">6.1.2. Separare le proprie patch in più file</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#multiple-binary">6.1.3. Pacchetti binari multipli</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="section">
<a href="ch06.html#bpp-debian-control">6.2. Buone pratiche per <code class="filename">debian/control</code></a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch06.html#bpp-desc-basics">6.2.1. Linee guida generali per le descrizioni dei pacchetti</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#bpp-pkg-synopsis">6.2.2. La sinossi del pacchetto, o una breve descrizione</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#bpp-pkg-desc">6.2.3. La descrizione lunga</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#bpp-upstream-info">6.2.4. Home page originale del pacchetto</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#bpp-vcs">6.2.5. La posizione del Version Control System</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch06.html#s6.2.5.1">6.2.5.1. Vcs-Browser</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#s6.2.5.2">6.2.5.2. Vcs-*</a>
</span>
</dt>
</dl>
</dd>
</dl>
</dd>
<dt>
<span class="section">
<a href="ch06.html#bpp-debian-changelog">6.3. Buone pratiche per il <code class="filename">debian/changelog</code></a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch06.html#bpp-changelog-do">6.3.1. Scrivere informazioni utili nel file changelog</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#bpp-changelog-misconceptions">6.3.2. Comuni incomprensioni sulle voci del changelog</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#bpp-changelog-errors">6.3.3. Errori frequenti nelle voci del changelog</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#bpp-news-debian">6.3.4. Integrare i changelog con i file <code class="filename">NEWS.Debian</code></a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="section">
<a href="ch06.html#bpp-debian-maint-scripts">6.4. Buone pratiche per gli script del mantainer</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#bpp-config-mgmt">6.5. Gestione della configurazione con <code class="systemitem">debconf</code></a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch06.html#s6.5.1">6.5.1. Non abusare di debconf</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#s6.5.2">6.5.2. Raccomandazioni generali per autori e traduttori</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch06.html#s6.5.2.1">6.5.2.1. Scrivere inglese corretto</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#s6.5.2.2">6.5.2.2. Sii gentile con i traduttori</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#s6.5.2.3">6.5.2.3. Ordinare intere traduzioni quando si correggono errori di battitura e di
ortografia</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#s6.5.2.4">6.5.2.4. Non fare ipotesi sulle interfacce</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#s6.5.2.5">6.5.2.5. Non utilizzare la prima persona</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#s6.5.2.6">6.5.2.6. Usare il genere neutro</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="section">
<a href="ch06.html#s6.5.3">6.5.3. Definizione dei campi dei modelli</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch06.html#s6.5.3.1">6.5.3.1. Tipo</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch06.html#s6.5.3.1.1">6.5.3.1.1. stringa</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#s6.5.3.1.2">6.5.3.1.2. password</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#s6.5.3.1.3">6.5.3.1.3. booleano</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#s6.5.3.1.4">6.5.3.1.4. seleziona</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#s6.5.3.1.5">6.5.3.1.5. multiselect</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#s6.5.3.1.6">6.5.3.1.6. nota</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#s6.5.3.1.7">6.5.3.1.7. testo</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#s6.5.3.1.8">6.5.3.1.8. errore</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="section">
<a href="ch06.html#s6.5.3.2">6.5.3.2. Descrizione: descrizione breve ed estesa</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#s6.5.3.3">6.5.3.3. Scelte</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#s6.5.3.4">6.5.3.4. Default</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="section">
<a href="ch06.html#s6.5.4">6.5.4. Guida a specifici stili di modelli di campi</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch06.html#s6.5.4.1">6.5.4.1. Type field</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#s6.5.4.2">6.5.4.2. Il campo Description</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch06.html#s6.5.4.2.1">6.5.4.2.1. Modelli di string/password</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#s6.5.4.2.2">6.5.4.2.2. Modelli booleani</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#s6.5.4.2.3">6.5.4.2.3. Selezione/Multiselezione</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#s6.5.4.2.4">6.5.4.2.4. Notes</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="section">
<a href="ch06.html#s6.5.4.3">6.5.4.3. Campo Choises</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#s6.5.4.4">6.5.4.4. Campo Default</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#s6.5.4.5">6.5.4.5. Campo Default</a>
</span>
</dt>
</dl>
</dd>
</dl>
</dd>
<dt>
<span class="section">
<a href="ch06.html#bpp-i18n">6.6. Internazionalizzazione</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch06.html#bpp-i18n-debconf">6.6.1. Gestione delle traduzioni debconf</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#bpp-i18n-docs">6.6.2. Documentazione internazionalizzata</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="section">
<a href="ch06.html#bpp-common-situations">6.7. Situazioni comuni durante la pacchettizzazione</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch06.html#bpp-autotools">6.7.1. Pacchettizzazione utilizzando
<span class="command"><strong>autoconf</strong></span>/<span class="command"><strong>automake</strong></span></a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#bpp-libraries">6.7.2. Le librerie</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#bpp-docs">6.7.3. La documentazione</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#bpp-other">6.7.4. Specifici tipi di pacchetti</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#bpp-archindepdata">6.7.5. Dati indipendenti dall'architettura</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#bpp-locale">6.7.6. Aver bisogno di una particolare localizzazione durante la compilazione</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#bpp-transition">6.7.7. Rendere i pacchetti di transizione conformi a deborphan</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#bpp-origtargz">6.7.8. Buone pratiche per i file <code class="filename">.orig.tar.{gz,bz2,xz}</code></a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch06.html#pristinesource">6.7.8.1. Sorgente puro</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#repackagedorigtargz">6.7.8.2. Sorgente originale ripacchettizzato</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#changed-binfiles">6.7.8.3. Modifica dei file binari</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="section">
<a href="ch06.html#bpp-dbg">6.7.9. Buone pratiche per i pacchetti di debug</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#bpp-meta">6.7.10. Buone pratiche per i metapacchetti</a>
</span>
</dt>
</dl>
</dd>
</dl>
</div>
<p>
La qualità della distribuzione Debian è in gran parte dovuta alla <a class="ulink" href="https://www.debian.org/doc/debian-policy/">Debian Policy</a>, che definisce i requisiti
di base espliciti che tutti i pacchetti Debian devono soddisfare. Ma vi è
anche una storia condivisa di esperienza che va oltre la policy Debian, un
accumulo di anni di esperienza nella pacchettizzazione. Molte persone di
grande talento hanno creato grandi strumenti, strumenti che aiutano voi, i
maintainer di Debian, a creare e mantenere ottimi pacchetti.
</p>
<p>
Questo capitolo fornisce alcune buone pratiche per gli sviluppatori
Debian. Tutte le raccomandazioni sono solo tali, e non sono requisiti o
policy. Questi sono solo alcuni spunti soggettivi, i consigli e i punti
raccolti da sviluppatori Debian. Ci si senta liberi di scegliere quello che
funziona meglio.
</p>
<div class="section">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a id="bpp-debian-rules"/>6.1. Buone pratiche per <code class="filename">debian/rules</code></h2>
</div>
</div>
</div>
<p>
Le seguenti raccomandazioni si applicano al file
<code class="filename">debian/rules</code>. Dal momento che il
<code class="filename">debian/rules</code> controlla il processo di generazione e
seleziona i file da inglobare nel pacchetto (direttamente o indirettamente),
è normale che i maintainer del file spendano molto tempo su di esso.
</p>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="helper-scripts"/>6.1.1. Script di supporto</h3>
</div>
</div>
</div>
<p>
L'idea nell'utilizzo degli script di aiuto in
<code class="filename">debian/rules</code> è che essi hanno consentito ai maintainer
di usare e condividere la logica comune tra molti pacchetti. Si prenda per
esempio la questione dell'installazione delle voci di menu: è necessario
mettere il file in <code class="filename">/usr/share/menu</code> (o
<code class="filename">/usr/lib/menu</code> per gli eseguibili binari dei menufile,
se questo è necessario), e aggiungere i comandi agli script del maintainer
per registrare ed annullare la registrazione delle voci di menu. Dal momento
che questa è una cosa molto comune da fare con i pacchetti, perché ogni
maintainer dovrebbe riscrivere tutto questo da solo, a volte con bug?
Inoltre, supponendo che la cartella menu cambi, ogni pacchetto dovrebbe
essere cambiato.
</p>
<p>
Gli script di supporto si occupano di questi problemi. Supponendo che ci si
attenga alle convenzioni previste dallo script di supporto, quest'ultimo si
prende cura di tutti i dettagli. Cambiamenti nella policy possono essere
effettuati nello script helper; successivamente i pacchetti avranno solo
bisogno di essere ricompilati con la nuova versione dell'helper e nessuna
ulteriore modifica.
</p>
<p>
<a class="xref" href="apa.html" title="Appendice A. Panoramica degli strumenti del Debian Maintainer">Appendice A, <em>Panoramica degli strumenti del Debian Maintainer</em></a> contiene un paio di diversi script di supporto. Il
sistema di supporto più comune e migliore (a nostro parere) è <code class="systemitem">debhelper</code>. I sistemi di supporto precedenti,
come <code class="systemitem">debmake</code>, erano monolitici: non
si poteva scegliere quale parte dell'helper si riteneva utile, ma si doveva
usare l'helper per fare tutto. <code class="systemitem">debhelper</code>, invece, è una serie di programmi
piccoli e separati <span class="command"><strong>dh_*</strong></span>. Per esempio,
<span class="command"><strong>dh_installman</strong></span> installa e comprime le pagine man,
<span class="command"><strong>dh_installmenu</strong></span> installa i file di menu, e così via. Così,
si offre sufficiente flessibilità per essere in grado di utilizzare i
piccoli script di aiuto, dove utile, in abbinamento con i comandi manuali in
<code class="filename">debian/rules</code>.
</p>
<p>
Si può iniziare con <code class="systemitem">debhelper</code>
leggendo <span class="citerefentry"><span class="refentrytitle">debhelper</span>(1)</span>, e guardando gli esempi distribuiti
con il pacchetto. <span class="command"><strong>dh_make</strong></span>, dal pacchetto <code class="systemitem">dh-make</code> (si consulti <a class="xref" href="apa.html#dh-make" title="A.3.2. dh-make">Sezione A.3.2, «<code class="systemitem">dh-make</code>»</a>),
può essere utilizzato per convertire un pacchetto sorgente normale in un
pacchetto <code class="systemitem">debhelper</code>izzato. Questa
scorciatoia, però, non deve convincere che non è necessario preoccuparsi di
capire i singoli script <span class="command"><strong>dh_ *</strong></span>. Se si ha intenzione di
utilizzare uno script di supporto, ci si deve concedere il tempo necessario
per imparare ad usare quello script, per imparare le sue previsioni e il suo
comportamento.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="multiple-patches"/>6.1.2. Separare le proprie patch in più file</h3>
</div>
</div>
</div>
<p>
Pacchetti grandi e complessi possono avere molti bug con cui ci si deve
rapportare. Se si corregge una serie di bug direttamente nel sorgente, e non
si sta attenti, può diventare difficile distinguere le varie patch che si
sono applicate. Può essere abbastanza caotico quando è necessario aggiornare
il pacchetto ad una nuova versione che integra alcune delle correzioni (ma
non tutte). Non si può prendere l'intero insieme di diff (ad esempio, da
<code class="filename">.diff.gz</code>) e capire quali patch occorrono per tornare
indietro di una unità man mano che i bug vengono corretti nel sorgente
originale.
</p>
<p>
Fortunatamente, con il formato sorgente «3.0 (quilt)» è ora possibile
mantenere le patch separate senza dover modificare
<code class="filename">debian/rules</code> per impostare un sistema di patch. Le
patch vengono memorizzate in <code class="filename">debian/patches/</code> e quando
il pacchetto sorgente è spacchettato le patch elencate nel
<code class="filename">debian/patches/series</code> vengono applicate
automaticamente. Come suggerisce il nome, le patch possono essere gestite
con <span class="command"><strong>quilt</strong></span>.
</p>
<p>
Quando si utilizza il più anziano sorgente «1.0», è anche possibile separare
le patch, ma un sistema di patch dedicato deve essere utilizzato: i file di
patch sono distribuiti all'interno del file di patch Debian
(<code class="filename">diff.gz</code>.), di solito nella cartella
<code class="filename">debian/</code>. L'unica differenza è che non vengono applicate
immediatamente da <span class="command"><strong>dpkg-source</strong></span>, ma dalla regola
<code class="literal">build</code> di <code class="filename">debian/rules</code>, attraverso
una dipendenza dalla regola <code class="literal">patch</code>. Al contrario, essi
sono annullati nella regola <code class="literal">clean</code>, attraverso una
dipendenza dalla regola <code class="literal">unpatch</code>.
</p>
<p>
<span class="command"><strong>quilt</strong></span> è lo strumento consigliato per questo. Fa tutto
quanto detto precedentemente e permette anche di gestire le serie di
patch. Si veda il pacchetto <code class="systemitem">quilt</code>
per ulteriori informazioni.
</p>
<p>
Ci sono altri strumenti per gestire le patch, come <span class="command"><strong>dpatch</strong></span>
e il sistema di patch integrato con <code class="systemitem">cdbs</code>.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="multiple-binary"/>6.1.3. Pacchetti binari multipli</h3>
</div>
</div>
</div>
<p>
Un singolo pacchetto sorgente costruirà spesso diversi pacchetti binari, sia
per fornire diverse versioni dello stesso software (ad esempio, il pacchetto
sorgente <code class="systemitem">vim</code>) o per fare diversi
piccoli pacchetti invece di uno grande (ad esempio, in modo che l'utente
possa installare solo il sottoinsieme necessario e quindi di risparmiare
spazio su disco).
</p>
<p>
Il secondo caso può essere facilmente gestito in
<code class="filename">debian/rules</code>. Bisogna solo spostare i file appropriati
dalla cartella di compilazione in alberi temporanei del pacchetto. È
possibile farlo utilizzando <span class="command"><strong>install</strong></span> o
<span class="command"><strong>dh_install</strong></span> da <code class="systemitem">debhelper</code>. Ci si assicuri di controllare le
diverse permutazioni dei vari pacchetti, assicurandosi di avere il corretto
insieme di dipendenze tra pacchetti in <code class="filename">debian/control</code>.
</p>
<p>
Il primo caso è un po' più difficile in quanto comporta molteplici
ricompilazioni dello stesso software, ma con diverse opzioni di
configurazione. Il pacchetto sorgente <code class="systemitem">vim</code> è un esempio di come gestirlo utilizzando un
file <code class="filename">debian/rules</code> scritto a mano.
</p>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a id="bpp-debian-control"/>6.2. Buone pratiche per <code class="filename">debian/control</code></h2>
</div>
</div>
</div>
<p>
Le seguenti pratiche sono rilevanti per il
file<code class="filename">debian/control</code>. Esse integrano la <a class="ulink" href="https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions">Policy sulla
descrizione dei pacchetti</a>.
</p>
<p>
La descrizione del pacchetto, come definito dal corrispondente campo nel
file <code class="filename">control</code>, contiene sia la sinossi del pacchetto sia
la descrizione lunga del pacchetto. <a class="xref" href="ch06.html#bpp-desc-basics" title="6.2.1. Linee guida generali per le descrizioni dei pacchetti">Sezione 6.2.1, «Linee guida generali per le descrizioni dei pacchetti»</a>
descrive le linee guida comuni ad entrambe le parti della descrizione del
pacchetto. In seguito, <a class="xref" href="ch06.html#bpp-pkg-synopsis" title="6.2.2. La sinossi del pacchetto, o una breve descrizione">Sezione 6.2.2, «La sinossi del pacchetto, o una breve descrizione»</a> fornisce
specifiche linee guida per la sinossi e <a class="xref" href="ch06.html#bpp-pkg-desc" title="6.2.3. La descrizione lunga">Sezione 6.2.3, «La descrizione lunga»</a>
contiene specifiche linee guida per la descrizione.
</p>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="bpp-desc-basics"/>6.2.1. Linee guida generali per le descrizioni dei pacchetti</h3>
</div>
</div>
</div>
<p>
La descrizione del pacchetto dovrebbe essere scritta probabilmente per
l'utente medio, la persona media che utilizzerà ed avrà benefici dal
pacchetto. Per esempio, pacchetti di sviluppo sono per gli sviluppatori e
possono essere di natura tecnica nella loro linguaggio. Applicazioni più
generiche, come gli editor, dovrebbero essere scritte per un utente meno
tecnico.
</p>
<p>
La nostra analisi delle descrizioni dei pacchetti ci porta a concludere che
la maggior parte delle descrizioni dei pacchetti sono di natura tecnica,
cosi è, non sono scritte per avere senso per gli utenti non tecnici. A meno
che il proprio pacchetto non sia realmente solo per utenti tecnici, questo
costituisce un problema.
</p>
<p>
Come si scrive per gli utenti non tecnici? Si eviti il gergo. Evitare di
riferirsi ad altre applicazioni o framework che l'utente potrebbe non
conoscere - GNOME o KDE va bene, dal momento che gli utenti hanno
probabilmente familiarità con questi termini, ma GTK+ probabilmente non lo
è. Cercare di ipotizzare nessuna conoscenza a priori. Se è necessario
utilizzare termini tecnici, spiegarli.
</p>
<p>
Si sia obiettivi. Le descrizioni dei pacchetti non sono il posto per
promuovere il proprio pacchetto, non importa quanto lo si ami. Ricordare che
il lettore potrebbe non essere interessato alle stesse cose che vi
interessano.
</p>
<p>
I riferimenti ai nomi di eventuali altri pacchetti software, nomi di
protocollo, standard o specifiche dovrebbero utilizzare la forma canonica,
se ne esiste una. Ad esempio, utilizzare X Window System, X11 o X, non X
Windows, X-Windows o X Window. Utilizzare GTK +, non GTK o gtk. Usare GNOME,
non Gnome. Utilizzare PostScript, non Postscript o postscript.
</p>
<p>
Se si hanno problemi di scrittura della descrizione, si potrebbe desiderare
di inviarla all'indirizzo di posta elettronica <code class="email"><<a class="email" href="mailto:debian-l10n-english@lists.debian.org">debian-l10n-english@lists.debian.org</a>></code>
richiedendo un parere.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="bpp-pkg-synopsis"/>6.2.2. La sinossi del pacchetto, o una breve descrizione</h3>
</div>
</div>
</div>
<p>
La policy dice che la linea di sinossi (la breve descrizione) deve essere
concisa ma anche informativa, non ripetendo il nome del pacchetto.
</p>
<p>
Le sinossi funziona come una frase che descrive il pacchetto, non una frase
completa, perciò la punteggiatura è inappropriata: non ha bisogno di lettere
maiuscole in più o un punto finale (punto). Dovrebbe anche omettere
qualsiasi iniziale articolo indefinito o definito - «a», «un» o «il». Così,
per esempio:
</p>
<pre class="screen">
Package: libeg0
Description: esempio di libreria di supporto
</pre>
<p>
Tecnicamente si tratta di un sintagma nominale senza articoli, al contrario
di una frase verbale. Una buona euristica è che dovrebbe essere possibile
sostituire il <em class="replaceable"><code>nome</code></em> e la
<em class="replaceable"><code>sinossi</code></em> del pacchetto in questa formula:
</p>
<p>
Il pacchetto <em class="replaceable"><code>name</code></em> fornisce {a, un, il, alcuni}
<em class="replaceable"><code>sinossi</code></em>.
</p>
<p>
Insiemi di pacchetti correlati possono utilizzare uno schema alternativo che
divide la sinossi in due parti, la prima una descrizione di tutta la suite e
la seconda una sintesi del ruolo del pacchetto all'interno di essa:
</p>
<pre class="screen">
Package: eg-tools
Description: simple exemplification system (utilities)
Package: eg-doc
Description: simple exemplification system - documentation
</pre>
<p>
Queste sinossi seguono una formula modificata. Quando un pacchetto
«<em class="replaceable"><code>name</code></em>» ha una «<em class="replaceable"><code>suite</code></em>
di sinossi (<em class="replaceable"><code>role</code></em>) » o
«<em class="replaceable"><code>suite</code></em> - <em class="replaceable"><code>role</code></em>», gli
elementi devono essere formulati in modo che si inseriscano nella formula:
</p>
<p>
Il <em class="replaceable"><code>name</code></em> del pacchetto fornisce {a, un, il}
<em class="replaceable"><code>role</code></em> per la <em class="replaceable"><code>suite</code></em>.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="bpp-pkg-desc"/>6.2.3. La descrizione lunga</h3>
</div>
</div>
</div>
<p>
La descrizione lunga è la principale informazione sul pacchetto disponibile
agli utenti prima che lo si installi. Essa dovrebbe fornire tutte le
informazioni necessarie per permettere all'utente di decidere se installare
il pacchetto. Si supponga che l'utente abbia già letto la sinossi del
pacchetto.
</p>
<p>
La descrizione lunga deve essere composta da frasi complete ed esaustive.
</p>
<p>
Il primo paragrafo della descrizione lunga deve rispondere alle seguenti
domande: che cosa fa il pacchetto? in che modo aiuta l'utente ad assolvere
ai suoi task? È importante descrivere ciò in maniera non tecnica, salvo
ovviamente quando il pacchetto è destinato ad una utenza tecnica.
</p>
<p>
I paragrafi che seguono devono rispondere alle seguenti domande: Perché,
come utente, ho bisogno di questo pacchetto? Quali altre caratteristiche ha
il pacchetto? Quali le caratteristiche e le carenze ci sono rispetto ad
altri pacchetti (per esempio, se si ha bisogno di X, usare Y invece)? Questo
pacchetto è correlato ad altri pacchetti in qualche modo che non viene
gestito dal gestore di pacchetti (per esempio, questo è il client per il
server foo)?
</p>
<p>
Fare attenzione ad evitare errori di ortografia e di grammatica. Ci si
assicuri di effettuare il controllo ortografico. Entrambi
<span class="command"><strong>ispell</strong></span> e <span class="command"><strong>aspell</strong></span> hanno modalità
speciali per il controllo del file <code class="filename">debian/control</code>:
</p>
<pre class="screen">
ispell -d american -g debian/control
</pre>
<pre class="screen">
aspell -d en -D -c debian/control
</pre>
<p>
Gli utenti di solito si aspettano che queste domande ricevano risposta nella
descrizione del pacchetto:
</p>
<div class="itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
<p>
Che cosa fa il pacchetto? Se si tratta di un componente aggiuntivo per un
altro pacchetto, allora la breve descrizione del pacchetto per il quale è un
componente aggiuntivo dovrebbe essere inserita qui.
</p>
</li>
<li class="listitem">
<p>
Perché dovrei volere questo pacchetto? Questo è legato al precedente, ma non
è lo stesso (questo è un client di posta elettronica; questo è eccezionale,
veloce, si interfaccia con PGP e LDAP e IMAP, ha caratteristiche X, Y e Z).
</p>
</li>
<li class="listitem">
<p>
Se il pacchetto non deve essere installato direttamente, ma è richiamato da
un altro pacchetto, questo dovrebbe essere menzionato.
</p>
</li>
<li class="listitem">
<p>
Se il pacchetto è <code class="literal">experimental</code>, o ci sono altri motivi
per i quali non dovrebbe essere usato, se invece ci sono altri pacchetti che
dovrebbero essere utilizzati, esso dovrebbe essere indicato.
</p>
</li>
<li class="listitem">
<p>
In che modo questo pacchetto si differenzia da altri? È un'implementazione
migliore? più funzioni? caratteristiche diverse? Perché dovrei scegliere
questo pacchetto.
</p>
</li>
</ul>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="bpp-upstream-info"/>6.2.4. Home page originale del pacchetto</h3>
</div>
</div>
</div>
<p>
Si consiglia di aggiungere l'URL per la home page del pacchetto nel campo
<code class="literal">Homepage</code> della sezione <code class="literal">Source</code> in
<code class="filename">debian/control</code>. L'aggiunta di questa informazione nella
descrizione del stesso pacchetto è considerata obsoleta.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="bpp-vcs"/>6.2.5. La posizione del Version Control System</h3>
</div>
</div>
</div>
<p>
Ci sono campi aggiuntivi per la posizione del Version Control System in
<code class="filename">debian/control</code>.
</p>
<div class="section">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="s6.2.5.1"/>6.2.5.1. Vcs-Browser</h4>
</div>
</div>
</div>
<p>
Il valore di questo campo dovrebbe essere una URL <code class="literal">http://</code>
che punta a una copia web navigabile del Version Control System utilizzato
per mantenere il pacchetto, se disponibile.
</p>
<p>
L'informazione è destinata ad essere utile per l'utente finale, disposto a
sfogliare l'ultimo lavoro svolto sul pacchetto (ad esempio quando si cerca
la patch di un bug etichettato come <code class="literal">pending</code> nel sistema
di bug tracking).
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="s6.2.5.2"/>6.2.5.2. Vcs-*</h4>
</div>
</div>
</div>
<p>
Il valore di questo campo deve essere una stringa che identifica in modo
inequivocabile la posizione del repository del Version Control System
utilizzato per mantenere il pacchetto, se disponibile. <code class="literal">*</code>
individua il Version Control System; attualmente i seguenti sistemi sono
supportati dal package tracking system: <code class="literal">arch</code>,
<code class="literal">bzr</code> (Bazaar), <code class="literal">cvs</code>,
<code class="literal">darcs</code>, <code class="literal">git</code>, <code class="literal">hg</code>
(Mercurial), <code class="literal">mtn</code> (Monotone), <code class="literal">svn</code>
(Subversion). È consentito specificare diversi campi VCS per lo stesso
pacchetto: saranno tutti mostrati nell'interfaccia web di PTS.
</p>
<p>
L'informazione è destinata ad essere utile per un utente esperto nel dato
Version Control System e disposto a compilare la versione attuale del
pacchetto dai sorgenti VCS. Altri usi di queste informazioni possono
includere compilazioni automatiche della versione VCS più recente del dato
pacchetto. A tal fine la posizione a cui punta il campo dovrebbe essere la
versione migliore rispetto a quella agnostica e puntare al ramo principale
(per i VCS che supportano tale concetto). Inoltre, la posizione indicata
dovrebbe essere accessibile per l'utente finale; soddisfare questo requisito
potrebbe implicare un accesso anonimo al repository invece di puntare a una
versione SSH-accessibile dello stesso.
</p>
<p>
Nel seguente esempio è mostrata un'istanza del campo per un repository
Subversion del pacchetto <code class="systemitem">vim</code>. Si
noti come l'URL è nello schema <code class="literal">svn://</code> (invece di
<code class="literal">svn+ssh://</code>) e come si punti al branch
<code class="filename">trunk/</code>. È anche mostrato l'uso dei campi del
<code class="literal">Vcs-Browser</code> e <code class="literal">Homepage</code> descritti
precedentemente.
</p>
<pre class="screen">
Source: vim
Section: editors
Priority: optional
<snip>
Vcs-Svn: svn://svn.debian.org/svn/pkg-vim/trunk/packages/vim
Vcs-Browser: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim
Homepage: http://www.vim.org
</pre>
</div>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a id="bpp-debian-changelog"/>6.3. Buone pratiche per il <code class="filename">debian/changelog</code></h2>
</div>
</div>
</div>
<p>
Le seguenti pratiche integrano la <a class="ulink" href="https://www.debian.org/doc/debian-policy/ch-docs.html#s-changelogs">Policy sui file
changelog</a>.
</p>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="bpp-changelog-do"/>6.3.1. Scrivere informazioni utili nel file changelog</h3>
</div>
</div>
</div>
<p>
La voce del changelog inerente una revisione del pacchetto documenta i
cambiamenti in quella specifica revisione e solo loro. Concentrarsi sulla
descrizione di cambiamenti significativi e visibili all'utente che sono
stati fatti dopo l'ultima versione.
</p>
<p>
Ci si concentri su <span class="emphasis"><em>ciò</em></span> che è stato cambiato: chi, come
e quando di solito sono meno importanti. Detto questo, ricordarsi di citare
le persone che hanno fornito un notevole aiuto nel compilare il pacchetto
(ad esempio, coloro che hanno inviato delle patch).
</p>
<p>
Non c'è bisogno di elaborare le modifiche banali e ovvie. È inoltre
possibile aggregare diversi cambiamenti in un'unica voce. D'altra parte, non
si sia troppo ermetici se si ha intrapreso un cambiamento importante. Si sia
particolarmente chiari se ci sono cambiamenti che influenzano il
comportamento del programma. Per ulteriori chiarimenti, utilizzare il
<code class="filename">README.Debian</code>.
</p>
<p>
Si utilizzi l'inglese comune in modo che la maggior parte dei lettori possa
comprenderlo. Si evitino abbreviazioni, termini tecnici e gergo quando si
spiegano i cambiamenti che chiudono i bug, soprattutto per i bug segnalati
dagli utenti che non sembrano particolarmente smaliziati dal punto di vista
tecnico. Si sia gentili, non si imprechi.
</p>
<p>
A volte è desiderabile far precedere le voci del changelog con i nomi dei
file che sono stati modificati. Tuttavia, non c'è bisogno di elencare
esplicitamente uno per uno tutti i file modificati, soprattutto se il
cambiamento è stato piccolo o ripetitivo. È possibile utilizzare i
metacaratteri.
</p>
<p>
Quando si parla di bug, non si dia per scontato nulla. Dire quale era il
problema, come è stato risolto e aggiungere in fondo la stringa closes:
#nnnnn. Per ulteriori informazioni, si consulti <a class="xref" href="ch05.html#upload-bugfix" title="5.8.4. Quando i bug vengono chiusi da nuovi upload">Sezione 5.8.4, «Quando i bug vengono chiusi da nuovi upload»</a>.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="bpp-changelog-misconceptions"/>6.3.2. Comuni incomprensioni sulle voci del changelog</h3>
</div>
</div>
</div>
<p>
Le voci del changelog <span class="strong"><strong>non</strong></span> dovrebbero
documentare generici problemi di packaging (Ehi, se si è alla ricerca di
foo.conf, è in /etc/blah/.), dal momento che si suppone che gli
amministratori e gli utenti siano a conoscenza di come queste cose sono
generalmente gestite sui sistemi Debian. Parlatene, tuttavia, se si modifica
la posizione di un file di configurazione.
</p>
<p>
Gli unici bug chiusi con una voce nel changelog dovrebbero essere quelli che
sono effettivamente chiusi nella stessa versione del pacchetto. Chiudere bug
non correlati nel changelog è cattiva pratica. Si veda <a class="xref" href="ch05.html#upload-bugfix" title="5.8.4. Quando i bug vengono chiusi da nuovi upload">Sezione 5.8.4, «Quando i bug vengono chiusi da nuovi upload»</a>.
</p>
<p>
Le voci del changelog <span class="strong"><strong>non</strong></span> dovrebbero
essere utilizzate per discussioni casuali con chi ha segnalato il bug (non
vedo segmentation fault quando avvio foo con l'opzione bar; invia più
informazioni al riguardo), dichiarazioni generali sulla vita, l'universo e
tutto il resto (scusate questo caricamento mi ha preso così tanto tempo, ma
ho preso l'influenza), o richieste di aiuto (la lista di bug su questo
pacchetto è enorme, vi prego di dare una mano). Queste cose di solito non
vengono notate, ma possono infastidire le persone che desiderano leggere le
informazioni sulle modifiche effettive nel pacchetto. Per ulteriori
informazioni su come utilizzare il sistema di bug tracking vedere <a class="xref" href="ch05.html#bug-answering" title="5.8.2. Rispondere ai bug">Sezione 5.8.2, «Rispondere ai bug»</a>.
</p>
<p>
Si tratta di una vecchia tradizione per riconoscere bug corretti in un
caricamento di un non-maintainer nella prima voce del changelog
dell'appropriato maintainer. Siccome ora abbiamo il version tracking, è
sufficiente mantenere le voci del changelog NMUed e citare questo fatto
nella propria voce del changelog.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="bpp-changelog-errors"/>6.3.3. Errori frequenti nelle voci del changelog</h3>
</div>
</div>
</div>
<p>
I seguenti esempi dimostrano alcuni errori comuni o di cattivo stile nelle
voci del changelog.
</p>
<pre class="screen">
* Fixed all outstanding bugs.
</pre>
<p>
Questo non dice ai lettori qualcosa di particolarmente utile, ovviamente.
</p>
<pre class="screen">
* Applied patch from Jane Random.
</pre>
<p>
Qual'era l'argomento della patch?
</p>
<pre class="screen">
* Late night install target overhaul.
</pre>
<p>
Revisione che ha completato cosa? L'ipotetica citazione notturna è lì a
ricordarci che non dovremmo fidarci di quel codice?
</p>
<pre class="screen">
* Fix vsync FU w/ ancient CRTs.
</pre>
<p>
Troppe sigle e non è troppo chiaro a quale la, uh, fsckup (ops, una
parolaccia!) si riferiva, o come è stato sistemato.
</p>
<pre class="screen">
* This is not a bug, closes: #nnnnnn.
</pre>
<p>
Innanzitutto, non c'è assolutamente alcun bisogno di caricare il pacchetto
per trasmettere queste informazioni; invece, utilizzare il sistema di bug
tracking. In secondo luogo, non c'è alcuna spiegazione del perché il
rapporto non è un bug.
</p>
<pre class="screen">
* Has been fixed for ages, but I forgot to close; closes: #54321.
</pre>
<p>
Se per qualche motivo non si è citato il numero di bug in una voce
precedente del changelog, non è un problema, basta chiudere normalmente il
bug nel BTS. Non c'è bisogno di toccare il file changelog, presumendo che la
descrizione della correzione sia già indicata (questo vale per le correzioni
da parte degli autori/manutentori, non c'è bisogno di tenere traccia dei bug
che hanno risolto secoli fa nel proprio changelog).
</p>
<pre class="screen">
* Closes: #12345, #12346, #15432
</pre>
<p>
Dov'è la descrizione? Se non è possibile pensare ad un messaggio
descrittivo, iniziare inserendo il titolo di ogni differente bug.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="bpp-news-debian"/>6.3.4. Integrare i changelog con i file <code class="filename">NEWS.Debian</code></h3>
</div>
</div>
</div>
<p>
Importanti novità sui i cambiamenti in un pacchetto possono anche essere
inserite nei file <code class="filename">NEWS.Debian</code>. Le notizie saranno
visualizzate da strumenti come <code class="systemitem">apt-listchanges</code>, prima di tutto il resto dei
changelog. Questo è il mezzo preferito per permettere all'utente di
conoscere i cambiamenti significativi in ??un pacchetto. È meglio che usare
le note di <code class="systemitem">debconf</code> in quanto è meno
fastidioso e l'utente può tornare indietro e vedere il file
<code class="filename">NEWS.Debian</code> dopo l'installazione. Ed è meglio rispetto
all'elencare i principali cambiamenti presenti in
<code class="filename">README.Debian</code>, dal momento che l'utente può facilmente
perderli.
</p>
<p>
Il formato del file è lo stesso di un file changelog Debian, ma lasciare
fuori gli asterischi e descrivere ogni notizia con un paragrafo completo
quando necessario, piuttosto che le più concise sintesi che andrebbero in un
changelog. È una buona idea eseguire il file attraverso
<code class="literal">dpkg-parsechangelog</code> per controllare la formattazione in
quanto durante la fase di compilazione non sarà controllata automaticamente
come è stato fatto per il changelog. Ecco un esempio di un vero e proprio
file <code class="filename">NEWS.Debian</code>:
</p>
<pre class="screen">
cron (3.0pl1-74) unstable; urgency=low
The checksecurity script is no longer included with the cron package:
it now has its own package, checksecurity. If you liked the
functionality provided with that script, please install the new
package.
-- Steve Greenland <stevegr@debian.org> Sat, 6 Sep 2003 17:15:03 -0500
</pre>
<p>
Il file <code class="filename">NEWS.Debian</code> è installato come
<code class="filename">/usr/share/doc/<em class="replaceable"><code>package</code></em>/NEWS.Debian.gz</code>.
È compresso e ha sempre quel nome, anche in pacchetti nativi Debian. Se si
utilizza <code class="literal">debhelper</code>,
<code class="literal">dh_installchangelogs</code> installerà il file
<code class="filename">debian/NEWS</code> per voi.
</p>
<p>
A differenza dei file changelog, non è necessario aggiornare il file
<code class="filename">NEWS.Debian</code> ad ogni rilascio. Aggiornarli solo se si ha
qualcosa particolarmente degna di nota che l'utente dovrebbe conoscere. Se
non si ha alcuna notizia, non c'è bisogno di fornire un file
<code class="filename">NEWS.Debian</code>. Nessuna notizia è una buona notizia!
</p>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a id="bpp-debian-maint-scripts"/>6.4. Buone pratiche per gli script del mantainer</h2>
</div>
</div>
</div>
<p>
Gli script del maintainer includono i file
<code class="filename">debian/postinst</code>, <code class="filename">debian/preinst</code>,
<code class="filename">debian/prerm</code> e
<code class="filename">debian/postrm</code>. Questi script si prendono cura di ogni
configurazione di installazione o disinstallazione del pacchetto che non è
gestito esclusivamente dalla creazione o dalla rimozione di file e
cartelle. Le seguenti istruzioni completano la <a class="ulink" href="https://www.debian.org/doc/debian-policy/">Debian Policy</a>.
</p>
<p>
Gli script del maintainer devono essere idempotenti. Ciò significa che è
necessario assicurarsi che nulla di male accadrà se lo script dovesse essere
invocato due volte dove di solito viene lanciato una volta sola.
</p>
<p>
Gli standard input e output possono essere reindirizzati (ad esempio nelle
pipe) per finalità di logging, quindi non utilizzateli come una tty.
</p>
<p>
Tutte le configurazioni suggerite o interattive devono essere ridotte al
minimo. Quando è necessario, si dovrebbe utilizzare il pacchetto <code class="systemitem">debconf</code> per l'interfaccia. Ricordare che il
suggerimento in ogni caso può esserci solo nella fase
<code class="literal">configure</code> dello script <code class="filename">postinst</code>.
</p>
<p>
Mantenere gli script del maintainer più semplici possibile. Si consiglia di
utilizzare puri script POSIX. Ricordate, se si ha bisogno di tutte le
funzioni di bash, lo script del maintainer deve avere una linea shebang per
bash. La shell POSIX o Bash sono preferite a quella Perl, poiché permettono
a <code class="systemitem">debhelper</code> di aggiungere facilmente
bit agli script.
</p>
<p>
Se si modificano gli script del maintainer, assicurarsi di testare la
rimozione del pacchetto, la doppia installazione e l'epurazione. Assicurarsi
che un pacchetto epurato sia completamente sparito, ovvero, deve rimuovere
tutti i file creati, direttamente o indirettamente, in tutti gli script del
maintainer.
</p>
<p>
Se è necessario verificare l'esistenza di un comando, si dovrebbe usare
qualcosa simile a
</p>
<pre class="programlisting">if [ -x /usr/sbin/install-docs ]; then...</pre>
<p>
Se non si desidera codificare il percorso di un comando nello script del
maintainer, la seguente funzione shell che soddisfa POSIX potrebbe essere
d'aiuto:
</p>
<pre class="programlisting">pathfind() {
OLDIFS="$IFS"
IFS=:
for p in $PATH; do
if [ -x "$p/$*" ]; then
IFS="$OLDIFS"
return 0
fi
done
IFS="$OLDIFS"
return 1
}</pre>
<p>
Si può utilizzare questa funzione per cercare il <code class="varname">$PATH</code> di
un nome di un comando, passato come argomento. Restituisce true (zero) se il
comando è stato trovato e false in caso contrario. Questo è davvero il modo
più portatile, dal momento che <code class="literal">command -v</code>,
<span class="command"><strong>type</strong></span> e <span class="command"><strong>which</strong></span> non sono POSIX.
</p>
<p>
Mentre <span class="command"><strong>which</strong></span> è una alternativa accettabile, dal momento
che fa parte del richiesto pacchetto <code class="systemitem">debianutils</code>, non è nella partizione di
root. Ovvero, è in <code class="filename">/usr/bin</code>, piuttosto che
<code class="filename">/bin</code>, quindi non può essere utilizzato in script che
vengono eseguiti prima che la partizione <code class="filename">/usr</code> sia
montata. La maggior parte degli script non avranno questo problema, però.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a id="bpp-config-mgmt"/>6.5. Gestione della configurazione con <code class="systemitem">debconf</code></h2>
</div>
</div>
</div>
<p>
<code class="systemitem">Debconf</code> è un sistema di gestione
della configurazione che può essere utilizzato da tutti i vari script per la
pacchettizzazione (principalmente <code class="filename">postinst</code>) per
richiedere indicazioni all'utente riguardo a come configurare il
pacchetto. Interazioni dirette degli utenti ora devono essere evitate a
favore dell'interazione con <code class="systemitem">debconf</code>. Ciò consentirà installazioni non
interattive in futuro.
</p>
<p>
Debconf è un grande strumento, ma è spesso mal utilizzato. Molti errori
comuni sono elencati nella pagina man di <span class="citerefentry"><span class="refentrytitle">debconf-devel</span>(7)</span>. È qualcosa che si deve leggere se si decide di usare
debconf. Inoltre, indichiamo qui alcune buone pratiche.
</p>
<p>
Queste linee guida comprendono un certo stile di scrittura e di
raccomandazioni tipografiche, considerazioni generali sull'uso di debconf e
raccomandazioni più specifiche per alcune parti della distribuzione (il
sistema di installazione, per esempio).
</p>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="s6.5.1"/>6.5.1. Non abusare di debconf</h3>
</div>
</div>
</div>
<p>
Da quando debconf è apparso in Debian, è stato ampiamente abusato e diverse
critiche ricevute dalla distribuzione Debian provengono dall'abuso di
debconf con la necessità di rispondere ad una vasta serie di domande prima
di installare ogni piccola cosa.
</p>
<p>
Riservare le note d'uso a ciò cui appartengono: al file
<code class="filename">NEWS.Debian</code>, o <code class="filename">README.Debian</code>. Le
si utilizzi solamente per le note importanti che possono influenzare
direttamente l'usabilità del pacchetto. Ricordare che le note bloccheranno
sempre l'installazione fino a quando saranno confermate o abbiano disturbato
l'utente tramite email.
</p>
<p>
Scegliere con cura le priorità delle domande negli script del maintainer. Si
consulti <span class="citerefentry"><span class="refentrytitle">debconf-devel</span>(7)</span> per i dettagli sulla priorità. La
maggior parte delle domande dovrebbero usare le priorità media e bassa.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="s6.5.2"/>6.5.2. Raccomandazioni generali per autori e traduttori</h3>
</div>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="s6.5.2.1"/>6.5.2.1. Scrivere inglese corretto</h4>
</div>
</div>
</div>
<p>
La maggior parte dei maintainer dei pacchetti Debian non sono di madrelingua
inglese. Quindi, la scrittura di modelli correttamente formulati, può non
essere facile per loro.
</p>
<p>
utilizzare (e abusare) della mailing list
<code class="email"><<a class="email" href="mailto:debian-l10n-english@lists.debian.org">debian-l10n-english@lists.debian.org</a>></code>. Avrete le vostre bozze di modelli corrette.
</p>
<p>
I modelli scritti male danno una cattiva immagine del pacchetto, del proprio
lavoro... o anche di Debian stesso.
</p>
<p>
Evitare il gergo tecnico il più possibile. Se alcuni termini suonano comuni
a voi, possono essere impossibili da comprendere per gli altri. Se non si
possono evitare, cercare di spiegarli (utilizzare la descrizione
estesa). Nel fare ciò, cercare di bilanciarsi tra verbosità e semplicità.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="s6.5.2.2"/>6.5.2.2. Sii gentile con i traduttori</h4>
</div>
</div>
</div>
<p>
I modelli debconf possono essere tradotti. Debconf, insieme al suo pacchetto
fratello <span class="command"><strong>po-debconf</strong></span> offre un framework semplice per
ottenere i modelli tradotti dai team di traduzione o anche dai singoli
individui.
</p>
<p>
Utilizzare i modelli basati su gettext. Installare <code class="systemitem">po-debconf</code> sul proprio sistema di sviluppo e
leggete la sua documentazione (<span class="command"><strong>man po-debconf</strong></span> è un buon
inizio).
</p>
<p>
Evitare di modificare i modelli troppo spesso. Cambiare i modelli di testo
produce più lavoro per i traduttori che avranno la loro traduzione
confusa. Una traduzione confusa è una frase per la quale l'originale sia
stata cambiata da quando è stata tradotta, quindi per essere utilizzabile
richiede alcuni aggiornamenti da parte di un traduttore. Quando i
cambiamenti sono abbastanza piccoli, la traduzione originale è conservata
nel file PO, ma contrassegnata come <code class="literal">fuzzy</code>.
</p>
<p>
Se si ha intenzione di modificare i modelli originali, utilizzare il sistema
di notifica fornito con il pacchetto <code class="systemitem">po-debconf</code>, vale a dire il
<span class="command"><strong>podebconf-report-po</strong></span>, per contattare i traduttori. I
Traduttori più attivi sono molto reattivi e ottenere il loro lavoro incluso
insieme con i vostri modelli modificati vi risparmierà caricamenti
aggiuntivi. Se si utilizzano modelli basati su gettext, il nome del
traduttore e gli indirizzi di posta elettronica sono menzionati negli header
dei file PO e saranno utilizzati da <span class="command"><strong>podebconf-report-po</strong></span>.
</p>
<p>
Un uso consigliato di ciò che questa utility è:
</p>
<pre class="programlisting">cd debian/po && podebconf-report-po --call --languageteam --withtranslators --deadline="+10 days"</pre>
<p>
Questo comando innanzitutto sincronizzerà i files PO e POT in
<code class="filename">debian/po</code> con i file dei modelli elencati in
<code class="filename">debian/po/POTFILES.in</code>. Poi, invierà una richiesta di
nuove traduzioni, nella mailing list <code class="email"><<a class="email" href="mailto:debian-i18n@lists.debian.org">debian-i18n@lists.debian.org</a>></code>. Infine, invierà
una richiesta per aggiornare la traduzione sia al team per il supporto della
lingua (menzionato nel campo <code class="literal">Language-Team</code> di ogni file
PO), sia all'ultimo traduttore (menzionato nel campo
<code class="literal">Last-translator</code>).
</p>
<p>
Dare una scadenza ai traduttori è sempre apprezzato, in modo tale che
possano organizzare il loro lavoro. Ricordare che alcuni gruppi di
traduzione hanno un processo formalizzato di traduzione/revisione e un
ritardo inferiore a 10 giorni è considerato irragionevole. Un ritardo più
breve mette troppa pressione sul team di traduzione e dovrebbe essere
utilizzato per modifiche di minore entità.
</p>
<p>
In caso di dubbio, si può anche contattare il team di traduzione per una
determinata lingua (debian-l10n-xxxxx@lists.debian.org), o la mailing list
<code class="email"><<a class="email" href="mailto:debian-i18n@lists.debian.org">debian-i18n@lists.debian.org</a>></code>.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="s6.5.2.3"/>6.5.2.3. Ordinare intere traduzioni quando si correggono errori di battitura e di
ortografia</h4>
</div>
</div>
</div>
<p>
Quando il testo di un modello debconf è corretto e si è <span class="strong"><strong>sicuri</strong></span> che la modifica <span class="strong"><strong>non</strong></span> influenzi le traduzioni, si sia gentili con i
traduttori e <span class="emphasis"><em>sistemare</em></span> le loro traduzioni.
</p>
<p>
Se non si fa così, l'intero modello non verrà tradotto fino a quando un
traduttore invierà un aggiornamento.
</p>
<p>
Per <span class="emphasis"><em>sistemare</em></span> le traduzioni, è possibile utilizzare
<span class="command"><strong>msguntypot</strong></span> (parte del pacchetto <code class="systemitem">po4a</code>).
</p>
<div class="orderedlist">
<ol class="orderedlist">
<li class="listitem">
<p>
Rigenerare i file POT e PO.
</p>
<pre class="programlisting">debconf-updatepo</pre>
</li>
<li class="listitem">
<p>
Creare una copia del file POT.
</p>
<pre class="programlisting">cp templates.pot templates.pot.orig</pre>
</li>
<li class="listitem">
<p>
Fare una copia di tutti i files PO.
</p>
<pre class="programlisting">mkdir po_fridge; cp *.po po_fridge</pre>
</li>
<li class="listitem">
<p>
Modificare i file dei modelli di debconf per correggere errori di battitura.
</p>
</li>
<li class="listitem">
<p>
Rigenerare i file POT e PO (di nuovo).
</p>
<pre class="programlisting">debconf-updatepo</pre>
<p>
A questo punto, la correzione dell'errore di battitura ha confuso tutte le
traduzioni e questo spiacevole cambiamento è l'unico tra i file PO della
vostra cartella principale e quella in frigo. Ecco come risolvere questa
situazione.
</p>
</li>
<li class="listitem">
<p>
Scartare la traduzione disordinata, ripristinare quella proveniente dal
frigo.
</p>
<pre class="programlisting">cp po_fridge/*.po.</pre>
</li>
<li class="listitem">
<p>
Unire manualmente i files PO con il nuovo file POT, ma prendendo
nell'account l'inutile disordine.
</p>
<pre class="programlisting">msguntypot -o templates.pot.orig -n templates.pot *.po</pre>
</li>
<li class="listitem">
<p>
Pulizia.
</p>
<pre class="programlisting">rm -rf templates.pot.orig po_fridge</pre>
</li>
</ol>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="s6.5.2.4"/>6.5.2.4. Non fare ipotesi sulle interfacce</h4>
</div>
</div>
</div>
<p>
I modelli di testo non dovrebbero fare riferimento ai widget appartenenti ad
alcune interfacce di debconf. Frasi come <span class="emphasis"><em>Se rispondi
SI...</em></span> non hanno alcun significato per gli utenti di interfacce
grafiche che utilizzano checkbox per le domande booleane.
</p>
<p>
I modelli di frasi dovrebbero anche evitare di menzionare i valori
predefiniti nella loro descrizione. Primo, perché questo è ridondante con i
valori visualizzati dagli utenti. Inoltre, perché questi valori predefiniti
possono essere diversi dalle scelte del maintainer (per esempio, quando il
database debconf è stato preconfigurato).
</p>
<p>
Più in generale, cercare di evitare di riferirsi alle azioni
dell'utente. Basta indicare i fatti.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="s6.5.2.5"/>6.5.2.5. Non utilizzare la prima persona</h4>
</div>
</div>
</div>
<p>
Si dovrebbe evitare l'uso della prima persona (<span class="emphasis"><em>Farò
questo...</em></span> o <span class="emphasis"><em>Consigliamo...</em></span>). Il computer non
è una persona ed i modelli debconf non parlano a nome degli sviluppatori
Debian. Si dovrebbe usare la costruzione impersonale. Per coloro di voi che
già hanno scritto pubblicazioni scientifiche, basta scrivere i vostri
modelli come quando si scrive un articolo scientifico. Tuttavia, provare a
utilizzare la voce attiva, se ancora possibile, come <span class="emphasis"><em>Abilitate
questo se...</em></span>, invece di <span class="emphasis"><em>Questo può essere attivata
se... </em></span>.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="s6.5.2.6"/>6.5.2.6. Usare il genere neutro</h4>
</div>
</div>
</div>
<p>
Il mondo è fatto di uomini e donne. Utilizzare le costruzioni di genere
neutro nelle vostre scritture.
</p>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="s6.5.3"/>6.5.3. Definizione dei campi dei modelli</h3>
</div>
</div>
</div>
<p>
Questa parte fornisce alcune informazioni che sono per lo più prese dal
manuale <span class="citerefentry"><span class="refentrytitle">debconf-devel</span>(7)</span>.
</p>
<div class="section">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="s6.5.3.1"/>6.5.3.1. Tipo</h4>
</div>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h5 class="title"><a id="s6.5.3.1.1"/>6.5.3.1.1. stringa</h5>
</div>
</div>
</div>
<p>
Risultati in un campo di input nel quale l'utente può digitare qualsiasi
frase.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h5 class="title"><a id="s6.5.3.1.2"/>6.5.3.1.2. password</h5>
</div>
</div>
</div>
<p>
Richiede all'utente una password. La si usi con cautela; si sia consapevoli
del fatto che la password che l'utente inserisce sarà scritta nel database
di debconf. Si dovrebbe cancellare quel valore fuori dal database appena è
possibile.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h5 class="title"><a id="s6.5.3.1.3"/>6.5.3.1.3. booleano</h5>
</div>
</div>
</div>
<p>
Una scelta vero/falso. Ricordare: vero/falso, <span class="strong"><strong>non
si/no</strong></span>...
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h5 class="title"><a id="s6.5.3.1.4"/>6.5.3.1.4. seleziona</h5>
</div>
</div>
</div>
<p>
Una scelta tra una serie di valori. Le scelte devono essere specificate in
un campo denominato «Choices». Separare i possibili valori con le virgole e
gli spazi, in questo modo: <code class="literal">Scelte: sì, no, forse</code>.
</p>
<p>
Se le scelte sono stringhe traducibili, il campo «Choices» può essere
contrassegnato come traducibile utilizzando <code class="literal">__Choices</code>. La
doppia sottolineatura suddividerà ogni scelta in una stringa separata.
</p>
<p>
Il sistema <span class="command"><strong>po-debconf</strong></span> offre anche interessanti
possibilità di marcare solamente <span class="strong"><strong>alcune</strong></span>
scelte come traducibili. Esempio:
</p>
<pre class="programlisting">
Template: foo/bar
Type: Select
#flag:translate:3
__Choices: PAL, SECAM, Other
_Description: TV standard:
Please choose the TV standard used in your country.
</pre>
<p>
In questo esempio, solo la stringa «Other» è traducibile, mentre altri sono
acronimi che non devono essere tradotti. Quanto sopra esposto consente solo
ad «Other» di essere inserito nei file PO e POT.
</p>
<p>
I modelli debconf con sistema a flag offrono molte di queste possibilità. La
pagina del manuale di <span class="citerefentry"><span class="refentrytitle">po-debconf</span>(7)</span> elenca tutte queste possibilità.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h5 class="title"><a id="s6.5.3.1.5"/>6.5.3.1.5. multiselect</h5>
</div>
</div>
</div>
<p>
Come per la selezione del tipo di dato, ad eccezione di quando l'utente può
scegliere un qualsiasi numero di elementi dall'elenco delle scelte (o
scegliere nessuno di loro).
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h5 class="title"><a id="s6.5.3.1.6"/>6.5.3.1.6. nota</h5>
</div>
</div>
</div>
<p>
Piuttosto che essere una questione di per sé, questo tipo di dato indica una
nota che può essere visualizzata all'utente. Dovrebbe essere usato solo per
le note importanti che l'utente in realtà dovrebbe vedere, dato che debconf
andrà incontro a grandi dolori per assicurarsi che l'utente la veda;
arrestando l'installazione per consentire loro di premere un tasto persino
inviandogli la nota tramite posta elettronica in alcuni casi.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h5 class="title"><a id="s6.5.3.1.7"/>6.5.3.1.7. testo</h5>
</div>
</div>
</div>
<p>
Questo tipo è ora considerato obsoleto: non usarlo.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h5 class="title"><a id="s6.5.3.1.8"/>6.5.3.1.8. errore</h5>
</div>
</div>
</div>
<p>
Questo tipo è progettato per gestire i messaggi di errore. È molto simile al
tipo di nota. Le interfacce possono presentarlo in modo diverso (per
esempio, la finestra di cdebconf disegna uno schermo rosso invece del solito
blu).
</p>
<p>
Si consiglia di utilizzare questo tipo per ogni messaggio che necessita
dell'attenzione dell'utente per una correzione di qualsiasi tipo.
</p>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="s6.5.3.2"/>6.5.3.2. Descrizione: descrizione breve ed estesa</h4>
</div>
</div>
</div>
<p>
Le descrizioni dei modelli constano di due parti: breve ed estesa. La
descrizione breve è nella linea «Description:» del modello.
</p>
<p>
La descrizione breve dovrebbe essere mantenuta breve (50 caratteri o giù di
lì) in modo che possa essere accolta dalla maggior parte delle interfacce di
debconf. Mantenerla breve aiuta anche i traduttori, considerato che
normalmente le traduzioni tendono a finire per essere più lunghe rispetto
all'originale.
</p>
<p>
La descrizione breve dovrebbe essere in grado di stare in piedi da
sola. Alcune interfacce non mostrano la descrizione lunga di default, oppure
solo se l'utente esplicitamente la chiede o addirittura non la mostrano
affatto. Evitare cose come «cosa vuoi fare?»
</p>
<p>
La descrizione breve non deve necessariamente essere un periodo
completo. Questo fa parte della raccomandazione di mantenerla breve ed
efficiente.
</p>
<p>
La descrizione estesa non deve ripetere la descrizione breve parola per
parola. Se non è possibile pensare ad una descrizione lunga, quindi primo,
si pensi un po' di più. Si condivida in debian-devel. Si chieda aiuto. Ci si
iscriva ad un corso di scrittura! La descrizione estesa è importante. Se
dopo tutto questo non è ancora possibile trovare qualcosa, la si lasci
vuota.
</p>
<p>
La descrizione estesa dovrebbe usare periodi completi. I paragrafi devono
essere brevi per migliorare la leggibilità. Non mescolare due idee nello
stesso punto, piuttosto si usi un altro paragrafo.
</p>
<p>
Non si sia troppo prolissi. Gli utenti tendono a ignorare schermate troppo
lunghe. 20 righe sono per esperienza un limite che non si dovrebbe
oltrepassare, perché ciò significa che nella finestra di interfaccia
classica, le persone avranno bisogno di scorrere e molte persone
semplicemente non lo fanno.
</p>
<p>
La descrizione estesa non dovrebbe <span class="strong"><strong>mai</strong></span>
includere una domanda.
</p>
<p>
Per specifiche regole inerenti il tipo di template (string, boolean, etc),
leggere qui di seguito.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="s6.5.3.3"/>6.5.3.3. Scelte</h4>
</div>
</div>
</div>
<p>
Questo campo dovrebbe essere utilizzato per la selezione singola e multipla
dei tipi. Esso contiene le scelte possibili che verranno presentate agli
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="s6.5.3.4"/>6.5.3.4. Default</h4>
</div>
</div>
</div>
<p>
Questo campo è facoltativo. Esso contiene la risposta predefinita per i
modelli di periodi, di selezione singola e multipla. Per i modelli di
selezione multipla, può contenere un elenco di scelte separate da virgole.
</p>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="s6.5.4"/>6.5.4. Guida a specifici stili di modelli di campi</h3>
</div>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="s6.5.4.1"/>6.5.4.1. Type field</h4>
</div>
</div>
</div>
<p>
Nessuna indicazione specifica eccetto: utilizzare il tipo appropriato,
facendo riferimento alla sezione precedente.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="s6.5.4.2"/>6.5.4.2. Il campo Description</h4>
</div>
</div>
</div>
<p>
Qui di seguito sono istruzioni specifiche per scrivere correttamente la
descrizione (breve e lunga) a seconda del tipo di modello.
</p>
<div class="section">
<div class="titlepage">
<div>
<div>
<h5 class="title"><a id="s6.5.4.2.1"/>6.5.4.2.1. Modelli di string/password</h5>
</div>
</div>
</div>
<div class="itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
<p>
La descrizione breve è un suggerimento e <span class="strong"><strong>non</strong></span> un titolo. Evitare domande in stile
suggerimento (indirizzo IP?) a favore di suggerimenti aperti (indirizzo
IP:). Si consiglia l'uso dei due punti.
</p>
</li>
<li class="listitem">
<p>
La descrizione estesa è un complemento della descrizione breve. Nella parte
estesa, si spieghi ciò che viene chiesto, piuttosto che riproporre la stessa
domanda con parole più lunghe. Utilizzare frasi complete. Una scrittura
concisa è fortemente sconsigliata.
</p>
</li>
</ul>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h5 class="title"><a id="s6.5.4.2.2"/>6.5.4.2.2. Modelli booleani</h5>
</div>
</div>
</div>
<div class="itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
<p>
La descrizione breve dovrebbe essere formulata in forma di una domanda che
dovrebbe essere mantenuta breve e dovrebbe generalmente terminare con un
traduzioni sono spesso più lunghe rispetto alle versioni originali).
</p>
</li>
<li class="listitem">
<p>
Anche in questo caso, evitare il riferimento a specifici widget delle
interfacce. Un errore comune per tali modelli è se si risponde con costrutti
di tipo Yes.
</p>
</li>
</ul>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h5 class="title"><a id="s6.5.4.2.3"/>6.5.4.2.3. Selezione/Multiselezione</h5>
</div>
</div>
</div>
<div class="itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
<p>
La descrizione breve è un suggerimento e <span class="strong"><strong>non</strong></span> un titolo. <span class="strong"><strong>Non</strong></span> utilizzare inutili costrutti del tipo
«Gentilmente scegliete...». Gli utenti sono abbastanza intelligenti da
capire che devono scegliere qualcosa... :)
</p>
</li>
<li class="listitem">
<p>
La descrizione estesa completerà la descrizione breve. Può far riferimento
alle scelte disponibili. Può anche indicare che l'utente può scegliere più
di una tra le scelte disponibili, se il modello è di tipo selezione multipla
(l'interfaccia spesso rende chiaro tutto ciò).
</p>
</li>
</ul>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h5 class="title"><a id="s6.5.4.2.4"/>6.5.4.2.4. Notes</h5>
</div>
</div>
</div>
<div class="itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
<p>
La descrizione breve dovrebbe essere considerata un <span class="strong"><strong>titolo</strong></span>.
</p>
</li>
<li class="listitem">
<p>
La descrizione estesa è ciò che sarà visualizzato come una spiegazione più
dettagliata della nota. Frasi, non scrittura sintetica.
</p>
</li>
<li class="listitem">
<p>
<span class="strong"><strong>Non abusare di debconf.</strong></span> Le note sono il
modo più comune per abusare di debconf. Come scritto nella pagina di manuale
di debconf-devel: è meglio usarle solo come avvertimento di problemi molto
seri. I files <code class="filename">NEWS.Debian</code> o
<code class="filename">README.Debian</code> sono il luogo appropriato per molte
note. Se, leggendo questo manuale, si sta valutando di convertire i propri
modelli di tipo Nota in voci di <code class="filename">NEWS.Debian</code> o
<code class="filename">README.Debian</code>, si consideri anche di mantenere le
traduzioni esistenti per il futuro.
</p>
</li>
</ul>
</div>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="s6.5.4.3"/>6.5.4.3. Campo Choises</h4>
</div>
</div>
</div>
<p>
Se le «Choises» sono suscettibili di cambiare spesso, considerare l'uso del
trucco «__ Choices». Questo dividerà ogni singola scelta in una singola
stringa, che aiuterà notevolmente i traduttori nel compiere il loro lavoro.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="s6.5.4.4"/>6.5.4.4. Campo Default</h4>
</div>
</div>
</div>
<p>
Se il valore di default, per un modello di selezione, può variare a seconda
della lingua dell'utente (per esempio, se la scelta è una scelta della
lingua), utilizzare il trucco «_Default».
</p>
<p>
Questo campo speciale permette ai traduttori di mettere la scelta più
appropriata in base alla loro propria lingua. Diventerà la scelta di default
quando sarà usato il loro linguaggio mentre la vostra «Scelta di Default»
verrà usata quando si utilizza l'inglese.
</p>
<p>
Esempio, tratto dai modelli del pacchetto geneweb:
</p>
<pre class="screen">
Template: geneweb/lang
Type: select
__Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv)
# This is the default choice. Translators may put their own language here
# instead of the default.
# WARNING : you MUST use the ENGLISH NAME of your language
# For instance, the french translator will need to put French (fr) here.
_Default: English[ translators, please see comment in PO files]
_Description: Geneweb default language:
</pre>
<p>
Si noti l'uso dei «cancelletti» che consentano i commenti interni nei campi
di debconf. Da notare anche l'uso di commenti che appariranno nel file sui
quali i traduttori lavoreranno.
</p>
<p>
I commenti sono necessari dal momento che il trucco _Default genera un po'
di confusione: i traduttori potranno mettere la propria scelta
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="s6.5.4.5"/>6.5.4.5. Campo Default</h4>
</div>
</div>
</div>
<p>
NON usare un campo predefinito vuoto. Se non si desidera utilizzare i valori
di Default, non usarli.
</p>
<p>
Se si utilizza po-debconf (e si <span class="strong"><strong>dovrebbe</strong></span>,
si consulti <a class="xref" href="ch06.html#s6.5.2.2" title="6.5.2.2. Sii gentile con i traduttori">Sezione 6.5.2.2, «Sii gentile con i traduttori»</a>), si consideri di marcare questo
campo come traducibile, se si pensa che possa essere tradotto.
</p>
<p>
Se il valore predefinito può variare a seconda della lingua/paese (ad
esempio, il valore predefinito per una scelta della lingua), è possibile
utilizzare il tipo speciale _Default documentato in <span class="citerefentry"><span class="refentrytitle">po-debconf</span>(7)</span>.
</p>
</div>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a id="bpp-i18n"/>6.6. Internazionalizzazione</h2>
</div>
</div>
</div>
<p>
Questa sezione contiene le informazioni a livello generale per gli
sviluppatori al fine di rendere più facile la vita dei traduttori. Maggiori
informazioni per i traduttori e gli sviluppatori interessati alla
internazionalizzazione sono disponibili nella documentazione <a class="ulink" href="https://people.debian.org/~jfs/debconf6/html/">Internazionalizzazione e localizzazione in
Debian</a>.
</p>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="bpp-i18n-debconf"/>6.6.1. Gestione delle traduzioni debconf</h3>
</div>
</div>
</div>
<p>
Come gli autori di port, i traduttori hanno un compito difficile. Lavorano
su molti pacchetti e devono collaborare con molti maintainer
diversi. Inoltre, la maggior parte delle volte, non sono di madrelingua
inglese, quindi si potrebbe dover essere particolarmente pazienti con loro.
</p>
<p>
L'obbiettivo di <code class="systemitem">debconf</code> era quello
di rendere più facile la configurazione di pacchetti per i maintainer e per
gli utenti. In origine, la traduzione di modelli debconf è stata gestita con
<span class="command"><strong>debconf-mergetemplate</strong></span>. Tuttavia, tale tecnica è ormai
deprecata, il modo migliore per realizzare una internazionalizzazione
<code class="systemitem">debconf</code> è quello di utilizzare il
pacchetto <code class="systemitem">po-debconf</code>. Questo metodo
è più facile sia per il maintainer e sia per i traduttori; sono forniti
script di transizione.
</p>
<p>
Utilizzando <code class="systemitem">po-debconf</code>, la
traduzione è memorizzata in file <code class="filename">.po</code> (prese dalle
tecniche di traduzione <span class="command"><strong>gettext</strong></span>). Speciali file di modello
contengono i messaggi originali e marcano quali campi sono
traducibili. Quando si modifica il valore di un campo traducibile, chiamando
<span class="command"><strong>debconf-updatepo</strong></span>, la traduzione è contrassegnata come
bisognosa di attenzione da parte dei traduttori. Poi, in fase di
compilazione, il programma <span class="command"><strong>dh_installdebconf</strong></span> si prende
cura di tutta la magia necessaria per aggiungere il modello con le
traduzioni aggiornate nei pacchetti binari. Fare riferimento alla pagina del
manuale di <span class="citerefentry"><span class="refentrytitle">po-debconf</span>(7)</span> per i dettagli.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="bpp-i18n-docs"/>6.6.2. Documentazione internazionalizzata</h3>
</div>
</div>
</div>
<p>
Internazionalizzare la documentazione è fondamentale per gli utenti, ma
richiede molto lavoro. Non c'è modo di eliminare tutto quel lavoro, ma si
possono rendere le cose più facili per i traduttori.
</p>
<p>
Se si mantiene una documentazione di qualsiasi dimensione, è più facile per
i traduttori se hanno accesso ad un sistema di controllo del codice
sorgente. Ciò consente ai traduttori di vedere le differenze tra due
versioni della documentazione, così, per esempio, si può vedere ciò che deve
essere ritradotto. Si raccomanda che la documentazione tradotta mantenga una
nota circa la versione del codice sulla quale è basata. Un sistema
interessante è fornito dal <a class="ulink" href="https://svn.debian.org/viewvc/d-i/trunk/manual/scripts/doc-check?view=co">doc-check</a> nel pacchetto <code class="systemitem">debian-installer</code>, che mostra una panoramica
dello stato di traduzione per ogni lingua, utilizzando i commenti
strutturati per la revisione in corso del file da tradurre e, per un file
tradotto, la revisione del file originale della traduzione sulla quale si
basa. Si potrebbe desiderare di adattarla e di fornirla nel proprio VCS.
</p>
<p>
Se si mantiene la documentazione XML o SGML, vi consigliamo di isolare
qualsiasi informazione indipendente dal linguaggio e definirla come entità
in un file separato che è incluso da tutte le diverse traduzioni. Ciò rende
molto più facile, per esempio, mantenere gli URL aggiornati in più file.
</p>
<p>
Alcuni strumenti (ad es <code class="systemitem">po4a</code>,
<code class="systemitem">poxml</code>, o il <code class="systemitem">translate-toolkit</code>) sono specializzati
nell'estrazione del materiale traducibile da diversi formati. Producono i
file PO, un formato abbastanza comune ai traduttori, che permette di vedere
ciò che deve essere ritradotto quando il documento tradotto viene
aggiornato.
</p>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a id="bpp-common-situations"/>6.7. Situazioni comuni durante la pacchettizzazione</h2>
</div>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="bpp-autotools"/>6.7.1. Pacchettizzazione utilizzando
<span class="command"><strong>autoconf</strong></span>/<span class="command"><strong>automake</strong></span></h3>
</div>
</div>
</div>
<p>
Mantenere i file <code class="filename">config.sub</code> e
<code class="filename">config.guess</code> di <span class="command"><strong>autoconf</strong></span> aggiornati
è fondamentale per gli autori di port, soprattutto su architetture più
volatili. Alcune ottime pratiche di packaging per ogni pacchetto che usa
<span class="command"><strong>autoconf</strong></span> e/o <span class="command"><strong>automake</strong></span> sono state
sintetizzate in <code class="filename">/usr/share/doc/autotools-dev/README.Debian.gz</code> dal pacchetto <code class="systemitem">autotools-dev</code>. Si è vivamente incoraggiati a
leggere questo file e di seguire le raccomandazioni in esso fornite.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="bpp-libraries"/>6.7.2. Le librerie</h3>
</div>
</div>
</div>
<p>
Le librerie sono sempre difficili da pacchettizzare per vari motivi. La
policy impone molti vincoli per facilitare il loro mantenimento e per
assicurarsi che gli aggiornamenti siano i più semplici possibili quando una
nuova versione viene pubblicata. Una rottura in una libreria può causare una
rottura in decine di pacchetti dipendenti.
</p>
<p>
Delle buone pratiche per la pacchettizzazione delle librerie sono state
raggruppate in <a class="ulink" href="http://www.netfort.gr.jp/~dancer/column/libpkg-guide/">Guida alla pacchettizzazione
delle librerie</a>.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="bpp-docs"/>6.7.3. La documentazione</h3>
</div>
</div>
</div>
<p>
Assicurarsi di seguire la policy <a class="ulink" href="https://www.debian.org/doc/debian-policy/ch-docs.html">Policy sulla documentazione</a>.
</p>
<p>
Se il pacchetto contiene la documentazione compilata a partire da XML o
SGML, si consiglia di non includere il sorgente XML o SGML nel pacchetto
binario. Se gli utenti vogliono il sorgente della documentazione, dovrebbero
poter recuperare il pacchetto sorgente.
</p>
<p>
La policy specifica che la documentazione deve essere fornita in formato
HTML. Si consiglia anche di inserire la documentazione in formato PDF e
testo normale se conveniente e se è possibile output di discreta
qualità. Tuttavia, non è in genere appropriato includere la versione in
testo semplice della documentazione il cui formato sorgente è HTML.
</p>
<p>
La maggior parte dei manuali dovrebbe registrarsi con <code class="systemitem">doc-base</code> durante l'installazione. Si consulti la
documentazione del pacchetto <code class="systemitem">doc-base</code> per ulteriori informazioni.
</p>
<p>
La policy di Debian (sezione 12.1) indica che le pagine del manuale
dovrebbero accompagnare ogni programma, utility e la funzione e suggerirli
per altri oggetti come file di configurazione. Se il lavoro che si sta
pacchettizzando non ha queste pagine di manuale, si consideri la loro
scrittura per l'inclusione nel pacchetto e di sottoporla allo sviluppatore
originale.
</p>
<p>
Le pagine man non necessitano di essere scritte direttamente in formato
troff. I formati file più diffusi sono DocBook, POD e di reST, che possono
essere convertiti usando <span class="command"><strong>xsltproc</strong></span>,
<span class="command"><strong>pod2man</strong></span> e <span class="command"><strong>rst2man</strong></span> rispettivamente. In
misura minore, il programma <span class="command"><strong>help2man</strong></span> può anche essere
utilizzato per scrivere uno stub.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="bpp-other"/>6.7.4. Specifici tipi di pacchetti</h3>
</div>
</div>
</div>
<p>
Vari tipi specifici di pacchetti hanno particolari sub-politiche e
rispettive pratiche e regole per la pacchettizzazione:
</p>
<div class="itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
<p>
I relativi pacchetti Perl hanno una <a class="ulink" href="https://www.debian.org/doc/packaging-manuals/perl-policy/">Perl
policy</a>, alcuni esempi di pacchetti che seguono tale policy sono
<code class="systemitem">libdbd-pg-perl</code> (modulo binario perl)
o <code class="systemitem">libmldbm-perl</code> (modulo perl
indipendente dall'architettura).
</p>
</li>
<li class="listitem">
<p>
I relativi pacchetti Python hanno la loro policy python; si consulti
<code class="filename">/usr/share/doc/python/python-policy.txt.gz</code> nel pacchetto <code class="systemitem">python</code>.
</p>
</li>
<li class="listitem">
<p>
I relativi pacchetti Emacs hanno la <a class="ulink" href="https://www.debian.org/doc/packaging-manuals/debian-emacs-policy">emacs
policy</a>.
</p>
</li>
<li class="listitem">
<p>
I relativi pacchetti Java hanno la loro <a class="ulink" href="https://www.debian.org/doc/packaging-manuals/java-policy/">java
policy</a>.
</p>
</li>
<li class="listitem">
<p>
I relativi pacchetti Ocaml hanno la loro politica, che si trova in
<code class="filename">/usr/share/doc/ocaml/ocaml_packaging_policy.gz</code> del pacchetto <code class="systemitem">ocaml</code>. Un buon esempio è il pacchetto dei
sorgenti di <code class="systemitem">camlzip</code>.
</p>
</li>
<li class="listitem">
<p>
I pacchetti che forniscono XML o SGML DTD devono essere conformi alle
indicazioni fornite nel pacchetto <code class="systemitem">sgml-base-doc</code>.
</p>
</li>
<li class="listitem">
<p>
I pacchetti Lisp si devono registrare con il <code class="systemitem">common-lisp-controller</code>, a proposito del quale si
veda <code class="filename">/usr/share/doc/common-lisp-controller/README.packaging</code>.
</p>
</li>
</ul>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="bpp-archindepdata"/>6.7.5. Dati indipendenti dall'architettura</h3>
</div>
</div>
</div>
<p>
Non è raro avere una grande quantità di dati indipendenti dall'architettura
pacchettizzati con un programma. Ad esempio, i file audio, una collezione di
icone, modelli di wallpaper, o altri file grafici. Se la dimensione di
questi dati è trascurabile rispetto alle dimensioni del resto del pacchetto,
probabilmente è meglio tenere il tutto in un unico pacchetto.
</p>
<p>
Tuttavia, se la dimensione dei dati è notevole, si consideri di dividere in
un pacchetto separato, indipendente dall'architettura
(<code class="filename">_all.deb</code>). In questo modo, si evitano inutili
duplicazioni degli stessi dati in undici o più .debs, uno per ogni
architettura. Mentre questo aggiunge un po' di overhead ai file dei
<code class="filename">Pacchetti</code>, fa risparmiare molto spazio su disco sui
mirror Debian. Separare i dati indipendenti dall'architettura riduce anche
il tempo di elaborazione di <span class="command"><strong>lintian</strong></span> (si consulti <a class="xref" href="apa.html#tools-lint" title="A.2. Strumenti per la pulizia di pacchetti">Sezione A.2, «Strumenti per la pulizia di pacchetti»</a>) quando lanciato sull'intero archivio Debian.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="bpp-locale"/>6.7.6. Aver bisogno di una particolare localizzazione durante la compilazione</h3>
</div>
</div>
</div>
<p>
Se si ha bisogno di una certa localizzazione durante la compilazione, si può
creare un file temporaneo con questo trucco:
</p>
<p>
Se si imposta <code class="varname">LOCPATH</code> all'equivalente di
<code class="filename">/usr/lib/locale</code> e <code class="varname">LC_ALL</code> al nome del
locale che si genera, si dovrebbe ottenere ciò che si desidera senza essere
root. Qualcosa di simile a questo:
</p>
<pre class="screen">
LOCALE_PATH=debian/tmpdir/usr/lib/locale
LOCALE_NAME=en_IN
LOCALE_CHARSET=UTF-8
mkdir -p $LOCALE_PATH
localedef -i $LOCALE_NAME.$LOCALE_CHARSET -f $LOCALE_CHARSET $LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET
# Using the locale
LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date
</pre>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="bpp-transition"/>6.7.7. Rendere i pacchetti di transizione conformi a deborphan</h3>
</div>
</div>
</div>
<p>
Deborphan è un programma per aiutare gli utenti ad individuare quali
pacchetti possono essere tranquillamente rimossi dal sistema, vale a dire
quelli che non hanno pacchetti dipendenti da loro. Il funzionamento
predefinito è di cercare solo all'interno delle sezioni libs e oldlibs, per
dare la caccia a librerie inutilizzate. Ma quando viene passato l'argomento
giusto, cerca di catturare altri pacchetti inutili.
</p>
<p>
Ad esempio, con <code class="literal">--guess-dummy</code>,
<span class="command"><strong>deborphan</strong></span> prova a cercare tutti i pacchetti di
transizione che sono stati necessari per l'aggiornamento, ma che ora possono
tranquillamente essere rimossi. Per questo, esso cerca la stringa dummy or
transitional nella loro descrizione breve.
</p>
<p>
Quindi, quando si crea un pacchetto di questo tipo, ci si assicuri di
aggiungere il testo alla descrizione breve. Se si è alla ricerca di esempi,
basta eseguire:<span class="command"><strong>apt-cache search.| grep dummy</strong></span> o
<span class="command"><strong>apt-cache search | grep transitional</strong></span>.
</p>
<p>
Inoltre, è raccomandato modificare la sua sezione in
<code class="literal">oldlibs</code> e la sua priorità in <code class="literal">extra</code> in
modo da cancellare il compito di <span class="command"><strong>deborphan</strong></span>.
</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="bpp-origtargz"/>6.7.8. Buone pratiche per i file <code class="filename">.orig.tar.{gz,bz2,xz}</code></h3>
</div>
</div>
</div>
<p>
Ci sono due tipi di tarball dei sorgenti originali: sorgente puro e sorgente
originale ripacchettizzato.
</p>
<div class="section">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="pristinesource"/>6.7.8.1. Sorgente puro</h4>
</div>
</div>
</div>
<p>
La caratteristica distintiva di un tarball sorgente incontaminato è che il
<code class="filename">.orig.tar.{gz,bz2,xz}</code> è byte-per-byte identico a un
tarball ufficialmente distribuito dall'autore originale. <a href="#ftn.idm2991" class="footnote" id="idm2991"><sup class="footnote">[5]</sup></a> Questo rende possibile l'utilizzo di checksum per
verificare facilmente che tutte le modifiche tra la versione di Debian e
quella originale siano contenute nel Debian diff. Inoltre, se il sorgente
originale è enorme, gli autori originali e chiunque possieda già l'archivio
originale possono risparmiare tempo di download, se vogliono ispezionare il
pacchetto in dettaglio.
</p>
<p>
Non ci sono linee guida universalmente accettate che gli autori originali
seguono per quanto riguarda la struttura delle cartelle all'interno del loro
tarball, ma <span class="command"><strong>dpkg-source</strong></span> è tuttavia in grado di affrontare
la maggior parte delle tarball originali come sorgente puro. La sua
strategia è equivalente alla seguente:
</p>
<div class="orderedlist">
<ol class="orderedlist">
<li class="listitem">
<p>
Si scompatta l'archivio in una cartella temporanea vuota facendo
</p>
<pre class="screen">
zcat path/to/<em class="replaceable"><code>packagename</code></em>_<em class="replaceable"><code>upstream-version</code></em>.orig.tar.gz | tar xf -
</pre>
</li>
<li class="listitem">
<p>
Se, dopo questo, la cartella temporanea non contiene nulla, ma una sola
cartella e nessun altro file, <span class="command"><strong>dpkg-source</strong></span> rinomina quella
cartella in
<code class="filename"><em class="replaceable"><code>packagename</code></em>-<em class="replaceable"><code>upstream-version</code></em>
(.orig)</code>. Il nome della più alta cartella nella tarball non ha
importanza, ed è tralasciata.
</p>
</li>
<li class="listitem">
<p>
In caso contrario, l'archivio originale deve essere stato confezionato senza
una comune cartella di livello alto (vergogna sull'autore originale!). In
questo caso, <span class="command"><strong>dpkg-source</strong></span> rinomina la cartella temporanea
<span class="emphasis"><em>stessa</em></span> in
<code class="filename"><em class="replaceable"><code>packagename</code></em>-<em class="replaceable"><code>upstream-version</code></em>
(.orig)</code>.
</p>
</li>
</ol>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="repackagedorigtargz"/>6.7.8.2. Sorgente originale ripacchettizzato</h4>
</div>
</div>
</div>
<p>
<span class="strong"><strong>Si dovrebbe</strong></span> caricare i pacchetti con un
tarball sorgente puro, se possibile, ma ci sono vari motivi per cui potrebbe
non essere possibile. Questo è il caso in cui se l'autore originale non
distribuisce il sorgente come non completamente compresso in formato tar, o
se il tarball originale contiene materiale non DFSG-free che è necessario
rimuovere prima di caricare.
</p>
<p>
In questi casi, lo sviluppatore deve costruirsi un
<code class="filename">.orig.tar.{gz,bz2,xz}</code> adatto. Ci si riferisce a un tale
tarball come sorgente originale ripacchettizato. Si noti che un sorgente
originale ripacchettizato è diverso da un pacchetto Debian nativo. Un
sorgente originale ripacchettizato con modifiche specifiche per Debian
ancora viene distribuito in un separato <code class="filename">.diff.gz</code> o
<code class="filename">.debian.tar.{gz,bz2,xz}</code> e ha ancora un numero di
versione composto da <em class="replaceable"><code>upstream-version</code></em> e
<em class="replaceable"><code>debian-version</code></em>.
</p>
<p>
Ci possono essere casi in cui è auspicabile pacchettizzare nuovamente il
sorgente anche se l'autore originale distribuisce un
<code class="filename">.tar.{gz,bz2,xz}</code> che potrebbe in linea di principio
essere utilizzato nella sua forma originaria. Il più ovvio è se un
<span class="emphasis"><em>significativo</em></span> risparmio di spazio può essere ottenuto
ricomprimendo l'archivio tar o rimuovendo genuinamente dell'inutile fuffa
dall'archivio originale. Si usi la propria discrezione qui, ma si sia pronti
a difendere la propria decisione se si pacchettizza nuovamente il sorgente
che poteva esser puro.
</p>
<p>
Un <code class="filename">.orig.tar.{gz,bz2,xz}</code> ripacchettizzato
</p>
<div class="orderedlist">
<ol class="orderedlist">
<li class="listitem">
<p>
<span class="strong"><strong>dovrebbe</strong></span> essere documentata nel pacchetto
sorgente risultante. Informazioni dettagliate su come è stato ottenuto il
sorgente ripacchettizzato e su come questo può essere riprodotto dovrebbero
essere fornite in <code class="filename">debian/copyright</code>. È anche una buona
idea fornire un <code class="literal">get-orig-source</code> target nel proprio
<code class="filename">debian/rules</code>, che ripete il processo, come descritto
nel Policy Manual, <a class="ulink" href="https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules">Script principale per
la compilazione: <code class="filename">debian/rules</code></a>.
</p>
</li>
<li class="listitem">
<p>
<span class="strong"><strong>non dovrebbe</strong></span> contenere qualsiasi tipo di
file che non proviene dall'autore originale, o il cui contenuto è stato
modificato. <a href="#ftn.idm3045" class="footnote" id="idm3045"><sup class="footnote">[6]</sup></a>
</p>
</li>
<li class="listitem">
<p>
<span class="strong"><strong>dovrebbe</strong></span>, salvo che per motivi legali,
preservare l'intera infrastruttura per la compilazione e per la portabilità
fornita dall'autore originale. Ad esempio, non è una ragione sufficiente per
omettere un file che viene utilizzato solo quando si compila su MS-DOS. Allo
stesso modo, un <code class="filename">Makefile</code> fornito dall'autore originale
non dovrebbe essere omesso anche se la prima cosa che il proprio
<code class="filename">debian/rules</code> fa è sovrascriverlo eseguendo uno script
di configurazione.
</p>
<p>
(<span class="emphasis"><em>Motivazione:</em></span> È comune per gli utenti Debian che hanno
bisogno di compilare software per piattaforme non-Debian prendere il
sorgente da uno dei mirror Debian piuttosto che cercare di individuare un
punto canonico di distribuzione originale).
</p>
</li>
<li class="listitem">
<p>
<span class="strong"><strong>dovrebbe</strong></span> usare
<code class="filename"><em class="replaceable"><code>packagename</code></em>-<em class="replaceable"><code>upstream-version</code></em>.orig</code>
come nome per la più alta cartella nel suo tarball. Ciò rende possibile
distinguere tarball puri da quelli ripacchettizzati.
</p>
</li>
<li class="listitem">
<p>
<span class="strong"><strong>dovrebbe</strong></span> essere compresso con gzip o bzip
con la massima compressione.
</p>
</li>
</ol>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="changed-binfiles"/>6.7.8.3. Modifica dei file binari</h4>
</div>
</div>
</div>
<p>
A volte è necessario cambiare file binari contenuti nel tarball originale, o
per aggiungere file binari che non vi sono contenuti. Questo è completamente
supportato quando si usano pacchetti sorgente in formato «3.0 (quilt)», si
consulti la pagina di manuale <span class="citerefentry"><span class="refentrytitle">dpkg-source</span>(1)</span> per i dettagli. Quando si utilizza il vecchio formato «1.0»,
i file binari non possono essere memorizzati nel
<code class="filename">.diff.gz</code> quindi è necessario memorizzare un
<span class="command"><strong>uuencode</strong></span>d (o simile) versione del file e decodificarlo in
fase di compilazione in <code class="filename">debian/rules</code> (e spostarlo nella
sua posizione ufficiale).
</p>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="bpp-dbg"/>6.7.9. Buone pratiche per i pacchetti di debug</h3>
</div>
</div>
</div>
<p>
Un pacchetto di debug è un pacchetto con un nome che termina in -dbg, che
contiene ulteriori informazioni che <span class="command"><strong>gdb</strong></span> può
utilizzare. Poiché i binari di Debian vengono separati di default, le
informazioni di debug, compresi i nomi delle funzioni e numeri di riga, non
sono disponibili quando si esegue <span class="command"><strong>gdb</strong></span> su binari Debian. I
pacchetti di debug consentono di installarli agli utenti che hanno bisogno
di queste informazioni aggiuntive, senza appesantire un regolare sistema con
queste informazioni.
</p>
<p>
Spetta al maintainer di un pacchetto se creare un pacchetto di debug o
meno. I maintainer sono incoraggiati a creare i pacchetti di debug per i
pacchetti di libreria, dal momento che questi possono aiutare nel debug di
molti programmi legati ad una libreria. In generale, i pacchetti di debug
non devono essere aggiunti per tutti i programmi, facendo così appesantire
l'archivio. Ma se un maintainer ritiene che gli utenti spesso hanno bisogno
di una versione di debug di un programma, può essere utile fare un pacchetto
di debug. I programmi che fanno parte dell'infrastruttura di base, come ad
esempio Apache e il server X sono anche dei buoni candidati per i pacchetti
di debug.
</p>
<p>
Alcuni pacchetti di debug possono contenere un completo e particolare
versione di debug compilata di una libreria o di altro binario, ma la
maggior parte di loro può risparmiare spazio e tempo di compilazione
contenendo invece simboli di debug separati che <span class="command"><strong>gdb</strong></span> è in
grado di trovare e caricare al volo quando si effettua il debug di un
programma o di una libreria. La convenzione in Debian è quella di mantenere
questi simboli in
<code class="filename">/usr/lib/debug/<em class="replaceable"><code>path</code></em></code>, dove
<em class="replaceable"><code>path</code></em> è il percorso al file eseguibile o alla
libreria. Ad esempio, i simboli di debug per
<code class="filename">/usr/bin/foo</code> vanno in
<code class="filename">/usr/lib/debug/usr/bin/foo</code> e simboli di debug per
<code class="filename">/usr/lib/libfoo.so.1</code> vanno in
<code class="filename">/usr/lib/debug/usr/lib/libfoo.so.1</code>.
</p>
<p>
I simboli di debug possono essere estratti da un file oggetto usando
<span class="command"><strong>objcopy - only-keep-debug</strong></span>. Successivamente il file
oggetto può essere spogliato e <span class="command"><strong>objcopy -
add-gnu-debuglink</strong></span> è utilizzato per specificare il percorso del
file di simboli di debug. <span class="citerefentry"><span class="refentrytitle">objcopy</span>(1)</span> spiega nel dettaglio come funziona questo processo.
</p>
<p>
Il comando <span class="command"><strong>dh_strip</strong></span> in <code class="systemitem">debhelper</code> supporta la creazione di pacchetti di
debug e può prendersi cura per voi di utilizzare <span class="command"><strong>objcopy</strong></span>
per separare i simboli di debug. Se il pacchetto utilizza <code class="systemitem">debhelper</code>, tutto quello che dovete fare è
chiamare <span class="command"><strong>dh_strip - DBG-package = libfoo-dbg</strong></span>, ed
aggiungere una voce al <code class="filename">debian/control</code> per il pacchetto
di debug.
</p>
<p>
Si noti che il pacchetto di debug dovrebbe dipendere dal pacchetto per il
quale fornisce i simboli di debug e questa dipendenza dovrebbe essere
versionata. Per esempio:
</p>
<pre class="screen">
Depends: libfoo (= ${binary:Version})
</pre>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="bpp-meta"/>6.7.10. Buone pratiche per i metapacchetti</h3>
</div>
</div>
</div>
<p>
Un metapacchetto è un pacchetto per lo più vuoto che rende facile installare
un insieme coerente di pacchetti che possono evolvere nel tempo. Realizza
ciò creando una dipendenza per tutti i pacchetti dell'insieme. Grazie alla
potenza di APT, il maintainer del metapacchetto può sistemare le dipendenze
e il sistema dell'utente otterrà automaticamente i pacchetti
supplementari. I pacchetti eliminati che sono stati installati
automaticamente verranno contrassegnati come candidati alla rimozione (e
saranno anche rimossi automaticamente da
<span class="command"><strong>aptitude</strong></span>). <code class="systemitem">gnome</code>
e <code class="systemitem">linux-image-amd64</code> sono due esempi
di metapacchetti (compilati dai pacchetti sorgente <code class="systemitem">meta-gnome2</code> e <code class="systemitem">linux-latest</code>).
</p>
<p>
La descrizione lunga del metapacchetto deve documentare chiaramente il suo
scopo in modo che l'utente sappia che cosa si perderà se rimuovono il
pacchetto. È raccomandato essere chiari sulle conseguenze. Ciò è
particolarmente importante per i metapacchetti che vengono installati
durante l'installazione iniziale e che non sono stati installati
esplicitamente dall'utente. Questi tendono ad essere importanti per
garantire regolari aggiornamenti del sistema e l'utente dovrebbe essere
disincentivato dal disinstallarli in modo da evitare potenziali rotture.
</p>
</div>
</div>
<div class="footnotes">
<br/>
<hr/>
<div id="ftn.idm2991" class="footnote">
<p><a href="#idm2991" class="para"><sup class="para">[5] </sup></a> Non possiamo impedire agli autori originali di cambiare il tarball che
distribuiscono senza anche incrementare il numero di versione, quindi non ci
può essere alcuna garanzia che in qualsiasi momento un tarball puro sia
identico a quello di upstream <span class="emphasis"><em>attualmente</em></span> in
distribuzione. Tutto ciò che ci si può aspettare è che sia identico a
qualcosa che l'autore originale una volta <span class="emphasis"><em>ha</em></span>
distribuito. Se una differenza dovesse emergere in seguito (ad esempio, se
l'upstream si accorgesse che non stava usando la massima compressione nella
distribuzione originale e dunque di comprimerlo nuovamente con
<span class="command"><strong>gzip</strong></span>), semplicemente non è una buona cosa. Poiché non vi
è alcun buon modo per caricare un nuovo
<code class="filename">.orig.tar.{gz,bz2,xz}</code> per la stessa versione, non c'è
nemmeno alcuna indicazione se trattare questa situazione come un bug. </p>
</div>
<div id="ftn.idm3045" class="footnote">
<p><a href="#idm3045" class="para"><sup class="para">[6] </sup></a> Come eccezione, se l'omissione di file non liberi porterebbe il sorgente a
fallire la compilazione senza assistenza da parte del Debian diff, potrebbe
essere opportuno modificare invece i file, omettendo solo le loro parti
non-free, o spiegare la situazione in un <code class="filename">README.source</code>
nella radice dell'albero del sorgente. Ma anche in questo caso sollecitare
l'autore originale affinché renda i componenti non liberi facilmente
separabili dal resto del sorgente. </p>
</div>
</div>
</div>
<div class="navfooter">
<hr/>
<table width="100%" summary="Navigation footer">
<tr>
<td align="left"><a accesskey="p" href="ch05.html"><img src="images/prev.png" alt="Indietro"/></a> </td>
<td align="center"> </td>
<td align="right"> <a accesskey="n" href="ch07.html"><img src="images/next.png" alt="Avanti"/></a></td>
</tr>
<tr>
<td align="left" valign="top">Capitolo 5. Gestione dei pacchetti </td>
<td align="center">
<a accesskey="h" href="index.html">
<img src="images/home.png" alt="Partenza"/>
</a>
</td>
<td align="right" valign="top"> Capitolo 7. Oltre la pacchettizzazione</td>
</tr>
</table>
</div>
</body>
</html>
|