/usr/share/doc/debian-policy/policy.html/ch-relationships.html is in debian-policy 3.9.3.1.
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 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
<title>Debian Policy Manual - Declaring relationships between packages</title>
<link href="index.html" rel="start">
<link href="ch-maintainerscripts.html" rel="prev">
<link href="ch-sharedlibs.html" rel="next">
<link href="index.html#contents" rel="contents">
<link href="index.html#copyright" rel="copyright">
<link href="ch-scope.html" rel="chapter" title="1 About this manual">
<link href="ch-archive.html" rel="chapter" title="2 The Debian Archive">
<link href="ch-binary.html" rel="chapter" title="3 Binary packages">
<link href="ch-source.html" rel="chapter" title="4 Source packages">
<link href="ch-controlfields.html" rel="chapter" title="5 Control files and their fields">
<link href="ch-maintainerscripts.html" rel="chapter" title="6 Package maintainer scripts and installation procedure">
<link href="ch-relationships.html" rel="chapter" title="7 Declaring relationships between packages">
<link href="ch-sharedlibs.html" rel="chapter" title="8 Shared libraries">
<link href="ch-opersys.html" rel="chapter" title="9 The Operating System">
<link href="ch-files.html" rel="chapter" title="10 Files">
<link href="ch-customized-programs.html" rel="chapter" title="11 Customized programs">
<link href="ch-docs.html" rel="chapter" title="12 Documentation">
<link href="ap-pkg-scope.html" rel="appendix" title="A Introduction and scope of these appendices">
<link href="ap-pkg-binarypkg.html" rel="appendix" title="B Binary packages (from old Packaging Manual)">
<link href="ap-pkg-sourcepkg.html" rel="appendix" title="C Source packages (from old Packaging Manual)">
<link href="ap-pkg-controlfields.html" rel="appendix" title="D Control files and their fields (from old Packaging Manual)">
<link href="ap-pkg-conffiles.html" rel="appendix" title="E Configuration file handling (from old Packaging Manual)">
<link href="ap-pkg-alternatives.html" rel="appendix" title="F Alternative versions of an interface - update-alternatives (from old Packaging Manual)">
<link href="ap-pkg-diversions.html" rel="appendix" title="G Diversions - overriding a package's version of a file (from old Packaging Manual)">
<link href="ch-scope.html#s1.1" rel="section" title="1.1 Scope">
<link href="ch-scope.html#s1.2" rel="section" title="1.2 New versions of this document">
<link href="ch-scope.html#s-authors" rel="section" title="1.3 Authors and Maintainers">
<link href="ch-scope.html#s-related" rel="section" title="1.4 Related documents">
<link href="ch-scope.html#s-definitions" rel="section" title="1.5 Definitions">
<link href="ch-archive.html#s-dfsg" rel="section" title="2.1 The Debian Free Software Guidelines">
<link href="ch-archive.html#s-sections" rel="section" title="2.2 Archive areas">
<link href="ch-archive.html#s-pkgcopyright" rel="section" title="2.3 Copyright considerations">
<link href="ch-archive.html#s-subsections" rel="section" title="2.4 Sections">
<link href="ch-archive.html#s-priorities" rel="section" title="2.5 Priorities">
<link href="ch-binary.html#s3.1" rel="section" title="3.1 The package name">
<link href="ch-binary.html#s-versions" rel="section" title="3.2 The version of a package">
<link href="ch-binary.html#s-maintainer" rel="section" title="3.3 The maintainer of a package">
<link href="ch-binary.html#s-descriptions" rel="section" title="3.4 The description of a package">
<link href="ch-binary.html#s-dependencies" rel="section" title="3.5 Dependencies">
<link href="ch-binary.html#s-virtual_pkg" rel="section" title="3.6 Virtual packages">
<link href="ch-binary.html#s3.7" rel="section" title="3.7 Base system">
<link href="ch-binary.html#s3.8" rel="section" title="3.8 Essential packages">
<link href="ch-binary.html#s-maintscripts" rel="section" title="3.9 Maintainer Scripts">
<link href="ch-source.html#s-standardsversion" rel="section" title="4.1 Standards conformance">
<link href="ch-source.html#s-pkg-relations" rel="section" title="4.2 Package relationships">
<link href="ch-source.html#s4.3" rel="section" title="4.3 Changes to the upstream sources">
<link href="ch-source.html#s-dpkgchangelog" rel="section" title="4.4 Debian changelog: debian/changelog">
<link href="ch-source.html#s-dpkgcopyright" rel="section" title="4.5 Copyright: debian/copyright">
<link href="ch-source.html#s4.6" rel="section" title="4.6 Error trapping in makefiles">
<link href="ch-source.html#s-timestamps" rel="section" title="4.7 Time Stamps">
<link href="ch-source.html#s-restrictions" rel="section" title="4.8 Restrictions on objects in source packages">
<link href="ch-source.html#s-debianrules" rel="section" title="4.9 Main building script: debian/rules">
<link href="ch-source.html#s-substvars" rel="section" title="4.10 Variable substitutions: debian/substvars">
<link href="ch-source.html#s-debianwatch" rel="section" title="4.11 Optional upstream source location: debian/watch">
<link href="ch-source.html#s-debianfiles" rel="section" title="4.12 Generated files list: debian/files">
<link href="ch-source.html#s-embeddedfiles" rel="section" title="4.13 Convenience copies of code">
<link href="ch-source.html#s-readmesource" rel="section" title="4.14 Source package handling: debian/README.source">
<link href="ch-controlfields.html#s-controlsyntax" rel="section" title="5.1 Syntax of control files">
<link href="ch-controlfields.html#s-sourcecontrolfiles" rel="section" title="5.2 Source package control files -- debian/control">
<link href="ch-controlfields.html#s-binarycontrolfiles" rel="section" title="5.3 Binary package control files -- DEBIAN/control">
<link href="ch-controlfields.html#s-debiansourcecontrolfiles" rel="section" title="5.4 Debian source control files -- .dsc">
<link href="ch-controlfields.html#s-debianchangesfiles" rel="section" title="5.5 Debian changes files -- .changes">
<link href="ch-controlfields.html#s-controlfieldslist" rel="section" title="5.6 List of fields">
<link href="ch-controlfields.html#s5.7" rel="section" title="5.7 User-defined fields">
<link href="ch-maintainerscripts.html#s6.1" rel="section" title="6.1 Introduction to package maintainer scripts">
<link href="ch-maintainerscripts.html#s-idempotency" rel="section" title="6.2 Maintainer scripts idempotency">
<link href="ch-maintainerscripts.html#s-controllingterminal" rel="section" title="6.3 Controlling terminal for maintainer scripts">
<link href="ch-maintainerscripts.html#s-exitstatus" rel="section" title="6.4 Exit status">
<link href="ch-maintainerscripts.html#s-mscriptsinstact" rel="section" title="6.5 Summary of ways maintainer scripts are called">
<link href="ch-maintainerscripts.html#s-unpackphase" rel="section" title="6.6 Details of unpack phase of installation or upgrade">
<link href="ch-maintainerscripts.html#s-configdetails" rel="section" title="6.7 Details of configuration">
<link href="ch-maintainerscripts.html#s-removedetails" rel="section" title="6.8 Details of removal and/or configuration purging">
<link href="ch-relationships.html#s-depsyntax" rel="section" title="7.1 Syntax of relationship fields">
<link href="ch-relationships.html#s-binarydeps" rel="section" title="7.2 Binary Dependencies - Depends, Recommends, Suggests, Enhances, Pre-Depends">
<link href="ch-relationships.html#s-breaks" rel="section" title="7.3 Packages which break other packages - Breaks">
<link href="ch-relationships.html#s-conflicts" rel="section" title="7.4 Conflicting binary packages - Conflicts">
<link href="ch-relationships.html#s-virtual" rel="section" title="7.5 Virtual packages - Provides">
<link href="ch-relationships.html#s-replaces" rel="section" title="7.6 Overwriting files and replacing packages - Replaces">
<link href="ch-relationships.html#s-sourcebinarydeps" rel="section" title="7.7 Relationships between source and binary packages - Build-Depends, Build-Depends-Indep, Build-Conflicts, Build-Conflicts-Indep">
<link href="ch-sharedlibs.html#s-sharedlibs-runtime" rel="section" title="8.1 Run-time shared libraries">
<link href="ch-sharedlibs.html#s-sharedlibs-support-files" rel="section" title="8.2 Shared library support files">
<link href="ch-sharedlibs.html#s-sharedlibs-static" rel="section" title="8.3 Static libraries">
<link href="ch-sharedlibs.html#s-sharedlibs-dev" rel="section" title="8.4 Development files">
<link href="ch-sharedlibs.html#s-sharedlibs-intradeps" rel="section" title="8.5 Dependencies between the packages of the same library">
<link href="ch-sharedlibs.html#s-sharedlibs-shlibdeps" rel="section" title="8.6 Dependencies between the library and other packages - the shlibs system">
<link href="ch-opersys.html#s9.1" rel="section" title="9.1 File system hierarchy">
<link href="ch-opersys.html#s9.2" rel="section" title="9.2 Users and groups">
<link href="ch-opersys.html#s-sysvinit" rel="section" title="9.3 System run levels and init.d scripts">
<link href="ch-opersys.html#s9.4" rel="section" title="9.4 Console messages from init.d scripts">
<link href="ch-opersys.html#s-cron-jobs" rel="section" title="9.5 Cron jobs">
<link href="ch-opersys.html#s-menus" rel="section" title="9.6 Menus">
<link href="ch-opersys.html#s-mime" rel="section" title="9.7 Multimedia handlers">
<link href="ch-opersys.html#s9.8" rel="section" title="9.8 Keyboard configuration">
<link href="ch-opersys.html#s9.9" rel="section" title="9.9 Environment variables">
<link href="ch-opersys.html#s-doc-base" rel="section" title="9.10 Registering Documents using doc-base">
<link href="ch-files.html#s-binaries" rel="section" title="10.1 Binaries">
<link href="ch-files.html#s-libraries" rel="section" title="10.2 Libraries">
<link href="ch-files.html#s10.3" rel="section" title="10.3 Shared libraries">
<link href="ch-files.html#s-scripts" rel="section" title="10.4 Scripts">
<link href="ch-files.html#s10.5" rel="section" title="10.5 Symbolic links">
<link href="ch-files.html#s10.6" rel="section" title="10.6 Device files">
<link href="ch-files.html#s-config-files" rel="section" title="10.7 Configuration files">
<link href="ch-files.html#s10.8" rel="section" title="10.8 Log files">
<link href="ch-files.html#s-permissions-owners" rel="section" title="10.9 Permissions and owners">
<link href="ch-customized-programs.html#s-arch-spec" rel="section" title="11.1 Architecture specification strings">
<link href="ch-customized-programs.html#s11.2" rel="section" title="11.2 Daemons">
<link href="ch-customized-programs.html#s11.3" rel="section" title="11.3 Using pseudo-ttys and modifying wtmp, utmp and lastlog">
<link href="ch-customized-programs.html#s11.4" rel="section" title="11.4 Editors and pagers">
<link href="ch-customized-programs.html#s-web-appl" rel="section" title="11.5 Web servers and applications">
<link href="ch-customized-programs.html#s-mail-transport-agents" rel="section" title="11.6 Mail transport, delivery and user agents">
<link href="ch-customized-programs.html#s11.7" rel="section" title="11.7 News system configuration">
<link href="ch-customized-programs.html#s11.8" rel="section" title="11.8 Programs for the X Window System">
<link href="ch-customized-programs.html#s-perl" rel="section" title="11.9 Perl programs and modules">
<link href="ch-customized-programs.html#s-emacs" rel="section" title="11.10 Emacs lisp programs">
<link href="ch-customized-programs.html#s11.11" rel="section" title="11.11 Games">
<link href="ch-docs.html#s12.1" rel="section" title="12.1 Manual pages">
<link href="ch-docs.html#s12.2" rel="section" title="12.2 Info documents">
<link href="ch-docs.html#s12.3" rel="section" title="12.3 Additional documentation">
<link href="ch-docs.html#s12.4" rel="section" title="12.4 Preferred documentation formats">
<link href="ch-docs.html#s-copyrightfile" rel="section" title="12.5 Copyright information">
<link href="ch-docs.html#s12.6" rel="section" title="12.6 Examples">
<link href="ch-docs.html#s-changelogs" rel="section" title="12.7 Changelog files">
<link href="ap-pkg-binarypkg.html#s-pkg-bincreating" rel="section" title="B.1 Creating package files - dpkg-deb">
<link href="ap-pkg-binarypkg.html#s-pkg-controlarea" rel="section" title="B.2 Package control information files">
<link href="ap-pkg-binarypkg.html#s-pkg-controlfile" rel="section" title="B.3 The main control information file: control">
<link href="ap-pkg-binarypkg.html#sB.4" rel="section" title="B.4 Time Stamps">
<link href="ap-pkg-sourcepkg.html#s-pkg-sourcetools" rel="section" title="C.1 Tools for processing source packages">
<link href="ap-pkg-sourcepkg.html#s-pkg-sourcetree" rel="section" title="C.2 The Debian package source tree">
<link href="ap-pkg-sourcepkg.html#s-pkg-sourcearchives" rel="section" title="C.3 Source packages as archives">
<link href="ap-pkg-sourcepkg.html#sC.4" rel="section" title="C.4 Unpacking a Debian source package without dpkg-source">
<link href="ap-pkg-controlfields.html#sD.1" rel="section" title="D.1 Syntax of control files">
<link href="ap-pkg-controlfields.html#sD.2" rel="section" title="D.2 List of fields">
<link href="ap-pkg-conffiles.html#sE.1" rel="section" title="E.1 Automatic handling of configuration files by dpkg">
<link href="ap-pkg-conffiles.html#sE.2" rel="section" title="E.2 Fully-featured maintainer script configuration handling">
<link href="ch-archive.html#s-main" rel="subsection" title="2.2.1 The main archive area">
<link href="ch-archive.html#s-contrib" rel="subsection" title="2.2.2 The contrib archive area">
<link href="ch-archive.html#s-non-free" rel="subsection" title="2.2.3 The non-free archive area">
<link href="ch-binary.html#s3.2.1" rel="subsection" title="3.2.1 Version numbers based on dates">
<link href="ch-binary.html#s-synopsis" rel="subsection" title="3.4.1 The single line synopsis">
<link href="ch-binary.html#s-extendeddesc" rel="subsection" title="3.4.2 The extended description">
<link href="ch-binary.html#s-maintscriptprompt" rel="subsection" title="3.9.1 Prompting in maintainer scripts">
<link href="ch-source.html#s-debianrules-options" rel="subsection" title="4.9.1 debian/rules and DEB_BUILD_OPTIONS">
<link href="ch-controlfields.html#s-f-Source" rel="subsection" title="5.6.1 Source">
<link href="ch-controlfields.html#s-f-Maintainer" rel="subsection" title="5.6.2 Maintainer">
<link href="ch-controlfields.html#s-f-Uploaders" rel="subsection" title="5.6.3 Uploaders">
<link href="ch-controlfields.html#s-f-Changed-By" rel="subsection" title="5.6.4 Changed-By">
<link href="ch-controlfields.html#s-f-Section" rel="subsection" title="5.6.5 Section">
<link href="ch-controlfields.html#s-f-Priority" rel="subsection" title="5.6.6 Priority">
<link href="ch-controlfields.html#s-f-Package" rel="subsection" title="5.6.7 Package">
<link href="ch-controlfields.html#s-f-Architecture" rel="subsection" title="5.6.8 Architecture">
<link href="ch-controlfields.html#s-f-Essential" rel="subsection" title="5.6.9 Essential">
<link href="ch-controlfields.html#s5.6.10" rel="subsection" title="5.6.10 Package interrelationship fields: Depends, Pre-Depends, Recommends, Suggests, Breaks, Conflicts, Provides, Replaces, Enhances">
<link href="ch-controlfields.html#s-f-Standards-Version" rel="subsection" title="5.6.11 Standards-Version">
<link href="ch-controlfields.html#s-f-Version" rel="subsection" title="5.6.12 Version">
<link href="ch-controlfields.html#s-f-Description" rel="subsection" title="5.6.13 Description">
<link href="ch-controlfields.html#s-f-Distribution" rel="subsection" title="5.6.14 Distribution">
<link href="ch-controlfields.html#s-f-Date" rel="subsection" title="5.6.15 Date">
<link href="ch-controlfields.html#s-f-Format" rel="subsection" title="5.6.16 Format">
<link href="ch-controlfields.html#s-f-Urgency" rel="subsection" title="5.6.17 Urgency">
<link href="ch-controlfields.html#s-f-Changes" rel="subsection" title="5.6.18 Changes">
<link href="ch-controlfields.html#s-f-Binary" rel="subsection" title="5.6.19 Binary">
<link href="ch-controlfields.html#s-f-Installed-Size" rel="subsection" title="5.6.20 Installed-Size">
<link href="ch-controlfields.html#s-f-Files" rel="subsection" title="5.6.21 Files">
<link href="ch-controlfields.html#s-f-Closes" rel="subsection" title="5.6.22 Closes">
<link href="ch-controlfields.html#s-f-Homepage" rel="subsection" title="5.6.23 Homepage">
<link href="ch-controlfields.html#s-f-Checksums" rel="subsection" title="5.6.24 Checksums-Sha1 and Checksums-Sha256">
<link href="ch-controlfields.html#s-f-DM-Upload-Allowed" rel="subsection" title="5.6.25 DM-Upload-Allowed">
<link href="ch-relationships.html#s7.6.1" rel="subsection" title="7.6.1 Overwriting files in other packages">
<link href="ch-relationships.html#s7.6.2" rel="subsection" title="7.6.2 Replacing whole packages, forcing their removal">
<link href="ch-sharedlibs.html#s-ldconfig" rel="subsection" title="8.1.1 ldconfig">
<link href="ch-sharedlibs.html#s8.6.1" rel="subsection" title="8.6.1 The shlibs files present on the system">
<link href="ch-sharedlibs.html#s8.6.2" rel="subsection" title="8.6.2 How to use dpkg-shlibdeps and the shlibs files">
<link href="ch-sharedlibs.html#s-shlibs" rel="subsection" title="8.6.3 The shlibs File Format">
<link href="ch-sharedlibs.html#s8.6.4" rel="subsection" title="8.6.4 Providing a shlibs file">
<link href="ch-opersys.html#s-fhs" rel="subsection" title="9.1.1 File System Structure">
<link href="ch-opersys.html#s9.1.2" rel="subsection" title="9.1.2 Site-specific programs">
<link href="ch-opersys.html#s9.1.3" rel="subsection" title="9.1.3 The system-wide mail directory">
<link href="ch-opersys.html#s-fhs-run" rel="subsection" title="9.1.4 /run and /run/lock">
<link href="ch-opersys.html#s9.2.1" rel="subsection" title="9.2.1 Introduction">
<link href="ch-opersys.html#s9.2.2" rel="subsection" title="9.2.2 UID and GID classes">
<link href="ch-opersys.html#s-/etc/init.d" rel="subsection" title="9.3.1 Introduction">
<link href="ch-opersys.html#s-writing-init" rel="subsection" title="9.3.2 Writing the scripts">
<link href="ch-opersys.html#s9.3.3" rel="subsection" title="9.3.3 Interfacing with the initscript system">
<link href="ch-opersys.html#s9.3.3.1" rel="subsection" title="9.3.3.1 Managing the links">
<link href="ch-opersys.html#s9.3.3.2" rel="subsection" title="9.3.3.2 Running initscripts">
<link href="ch-opersys.html#s9.3.4" rel="subsection" title="9.3.4 Boot-time initialization">
<link href="ch-opersys.html#s9.3.5" rel="subsection" title="9.3.5 Example">
<link href="ch-opersys.html#s-cron-files" rel="subsection" title="9.5.1 Cron job file names">
<link href="ch-files.html#s10.7.1" rel="subsection" title="10.7.1 Definitions">
<link href="ch-files.html#s10.7.2" rel="subsection" title="10.7.2 Location">
<link href="ch-files.html#s10.7.3" rel="subsection" title="10.7.3 Behavior">
<link href="ch-files.html#s10.7.4" rel="subsection" title="10.7.4 Sharing configuration files">
<link href="ch-files.html#s10.7.5" rel="subsection" title="10.7.5 User configuration files ("dotfiles")">
<link href="ch-files.html#s10.9.1" rel="subsection" title="10.9.1 The use of dpkg-statoverride">
<link href="ch-customized-programs.html#s-arch-wildcard-spec" rel="subsection" title="11.1.1 Architecture wildcards">
<link href="ch-customized-programs.html#s11.8.1" rel="subsection" title="11.8.1 Providing X support and package priorities">
<link href="ch-customized-programs.html#s11.8.2" rel="subsection" title="11.8.2 Packages providing an X server">
<link href="ch-customized-programs.html#s11.8.3" rel="subsection" title="11.8.3 Packages providing a terminal emulator">
<link href="ch-customized-programs.html#s11.8.4" rel="subsection" title="11.8.4 Packages providing a window manager">
<link href="ch-customized-programs.html#s11.8.5" rel="subsection" title="11.8.5 Packages providing fonts">
<link href="ch-customized-programs.html#s-appdefaults" rel="subsection" title="11.8.6 Application defaults files">
<link href="ch-customized-programs.html#s11.8.7" rel="subsection" title="11.8.7 Installation directory issues">
<link href="ch-docs.html#s-copyrightformat" rel="subsection" title="12.5.1 Machine-readable copyright information">
<link href="ap-pkg-sourcepkg.html#s-pkg-dpkg-source" rel="subsection" title="C.1.1 dpkg-source - packs and unpacks Debian source packages">
<link href="ap-pkg-sourcepkg.html#s-pkg-dpkg-buildpackage" rel="subsection" title="C.1.2 dpkg-buildpackage - overall package-building control script">
<link href="ap-pkg-sourcepkg.html#s-pkg-dpkg-gencontrol" rel="subsection" title="C.1.3 dpkg-gencontrol - generates binary package control files">
<link href="ap-pkg-sourcepkg.html#s-pkg-dpkg-shlibdeps" rel="subsection" title="C.1.4 dpkg-shlibdeps - calculates shared library dependencies">
<link href="ap-pkg-sourcepkg.html#s-pkg-dpkg-distaddfile" rel="subsection" title="C.1.5 dpkg-distaddfile - adds a file to debian/files">
<link href="ap-pkg-sourcepkg.html#s-pkg-dpkg-genchanges" rel="subsection" title="C.1.6 dpkg-genchanges - generates a .changes upload control file">
<link href="ap-pkg-sourcepkg.html#s-pkg-dpkg-parsechangelog" rel="subsection" title="C.1.7 dpkg-parsechangelog - produces parsed representation of a changelog">
<link href="ap-pkg-sourcepkg.html#s-pkg-dpkg-architecture" rel="subsection" title="C.1.8 dpkg-architecture - information about the build and host system">
<link href="ap-pkg-sourcepkg.html#s-pkg-debianrules" rel="subsection" title="C.2.1 debian/rules - the main building script">
<link href="ap-pkg-sourcepkg.html#s-pkg-srcsubstvars" rel="subsection" title="C.2.2 debian/substvars and variable substitutions">
<link href="ap-pkg-sourcepkg.html#sC.2.3" rel="subsection" title="C.2.3 debian/files">
<link href="ap-pkg-sourcepkg.html#sC.2.4" rel="subsection" title="C.2.4 debian/tmp">
<link href="ap-pkg-sourcepkg.html#sC.4.1" rel="subsection" title="C.4.1 Restrictions on objects in source packages">
<link href="ap-pkg-controlfields.html#s-pkg-f-Filename" rel="subsection" title="D.2.1 Filename and MSDOS-Filename">
<link href="ap-pkg-controlfields.html#s-pkg-f-Size" rel="subsection" title="D.2.2 Size and MD5sum">
<link href="ap-pkg-controlfields.html#s-pkg-f-Status" rel="subsection" title="D.2.3 Status">
<link href="ap-pkg-controlfields.html#s-pkg-f-Config-Version" rel="subsection" title="D.2.4 Config-Version">
<link href="ap-pkg-controlfields.html#s-pkg-f-Conffiles" rel="subsection" title="D.2.5 Conffiles">
<link href="ap-pkg-controlfields.html#sD.2.6" rel="subsection" title="D.2.6 Obsolete fields">
</head>
<body>
<p><a name="ch-relationships"></a></p>
<hr>
<p>
[ <a href="ch-maintainerscripts.html">previous</a> ]
[ <a href="index.html#contents">Contents</a> ]
[ <a href="ch-scope.html">1</a> ]
[ <a href="ch-archive.html">2</a> ]
[ <a href="ch-binary.html">3</a> ]
[ <a href="ch-source.html">4</a> ]
[ <a href="ch-controlfields.html">5</a> ]
[ <a href="ch-maintainerscripts.html">6</a> ]
[ 7 ]
[ <a href="ch-sharedlibs.html">8</a> ]
[ <a href="ch-opersys.html">9</a> ]
[ <a href="ch-files.html">10</a> ]
[ <a href="ch-customized-programs.html">11</a> ]
[ <a href="ch-docs.html">12</a> ]
[ <a href="ap-pkg-scope.html">A</a> ]
[ <a href="ap-pkg-binarypkg.html">B</a> ]
[ <a href="ap-pkg-sourcepkg.html">C</a> ]
[ <a href="ap-pkg-controlfields.html">D</a> ]
[ <a href="ap-pkg-conffiles.html">E</a> ]
[ <a href="ap-pkg-alternatives.html">F</a> ]
[ <a href="ap-pkg-diversions.html">G</a> ]
[ <a href="ch-sharedlibs.html">next</a> ]
</p>
<hr>
<h1>
Debian Policy Manual
<br>Chapter 7 - Declaring relationships between packages
</h1>
<hr>
<h2><a name="s-depsyntax"></a>7.1 Syntax of relationship fields</h2>
<p>
These fields all have a uniform syntax. They are a list of package names
separated by commas.
</p>
<p>
In the <samp>Depends</samp>, <samp>Recommends</samp>, <samp>Suggests</samp>,
<samp>Pre-Depends</samp>, <samp>Build-Depends</samp> and
<samp>Build-Depends-Indep</samp> control fields of the package, which declare
dependencies on other packages, the package names listed may also include lists
of alternative package names, separated by vertical bar (pipe) symbols
<samp>|</samp>. In such a case, if any one of the alternative packages is
installed, that part of the dependency is considered to be satisfied.
</p>
<p>
All of the fields except for <samp>Provides</samp> may restrict their
applicability to particular versions of each named package. This is done in
parentheses after each individual package name; the parentheses should contain
a relation from the list below followed by a version number, in the format
described in <a href="ch-controlfields.html#s-f-Version"><samp>Version</samp>,
Section 5.6.12</a>.
</p>
<p>
The relations allowed are <samp><<</samp>, <samp><=</samp>,
<samp>=</samp>, <samp>>=</samp> and <samp>>></samp> for strictly
earlier, earlier or equal, exactly equal, later or equal and strictly later,
respectively. The deprecated forms <samp><</samp> and <samp>></samp>
were used to mean earlier/later or equal, rather than strictly earlier/later,
so they should not appear in new packages (though <code>dpkg</code> still
supports them).
</p>
<p>
Whitespace may appear at any point in the version specification subject to the
rules in <a href="ch-controlfields.html#s-controlsyntax">Syntax of control
files, Section 5.1</a>, and must appear where it's necessary to disambiguate;
it is not otherwise significant. All of the relationship fields can only be
folded in source package control files. For consistency and in case of future
changes to <code>dpkg</code> it is recommended that a single space be used
after a version relationship and before a version number; it is also
conventional to put a single space after each comma, on either side of each
vertical bar, and before each open parenthesis. When opening a continuation
line in a relationship field, it is conventional to do so after a comma and
before the space following that comma.
</p>
<p>
For example, a list of dependencies might appear as:
</p>
<pre>
Package: mutt
Version: 1.3.17-1
Depends: libc6 (>= 2.2.1), exim | mail-transport-agent
</pre>
<p>
Relationships may be restricted to a certain set of architectures. This is
indicated in brackets after each individual package name and the optional
version specification. The brackets enclose a non-empty list of Debian
architecture names in the format described in <a
href="ch-customized-programs.html#s-arch-spec">Architecture specification
strings, Section 11.1</a>, separated by whitespace. Exclamation marks may be
prepended to each of the names. (It is not permitted for some names to be
prepended with exclamation marks while others aren't.)
</p>
<p>
For build relationship fields (<samp>Build-Depends</samp>,
<samp>Build-Depends-Indep</samp>, <samp>Build-Conflicts</samp> and
<samp>Build-Conflicts-Indep</samp>), if the current Debian host architecture is
not in this list and there are no exclamation marks in the list, or it is in
the list with a prepended exclamation mark, the package name and the associated
version specification are ignored completely for the purposes of defining the
relationships.
</p>
<p>
For example:
</p>
<pre>
Source: glibc
Build-Depends-Indep: texinfo
Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
hurd-dev [hurd-i386], gnumach-dev [hurd-i386]
</pre>
<p>
requires <samp>kernel-headers-2.2.10</samp> on all architectures other than
hurd-i386 and requires <samp>hurd-dev</samp> and <samp>gnumach-dev</samp> only
on hurd-i386.
</p>
<p>
For binary relationship fields, the architecture restriction syntax is only
supported in the source package control file <code>debian/control</code>. When
the corresponding binary package control file is generated, the relationship
will either be omitted or included without the architecture restriction based
on the architecture of the binary package. This means that architecture
restrictions must not be used in binary relationship fields for
architecture-independent packages (<samp>Architecture: all</samp>).
</p>
<p>
For example:
</p>
<pre>
Depends: foo [i386], bar [amd64]
</pre>
<p>
becomes <samp>Depends: foo</samp> when the package is built on the
<samp>i386</samp> architecture, <samp>Depends: bar</samp> when the package is
built on the <samp>amd64</samp> architecture, and omitted entirely in binary
packages built on all other architectures.
</p>
<p>
If the architecture-restricted dependency is part of a set of alternatives
using <samp>|</samp>, that alternative is ignored completely on architectures
that do not match the restriction. For example:
</p>
<pre>
Build-Depends: foo [!i386] | bar [!amd64]
</pre>
<p>
is equivalent to <samp>bar</samp> on the i386 architecture, to <samp>foo</samp>
on the amd64 architecture, and to <samp>foo | bar</samp> on all other
architectures.
</p>
<p>
Relationships may also be restricted to a certain set of architectures using
architecture wildcards in the format described in <a
href="ch-customized-programs.html#s-arch-wildcard-spec">Architecture wildcards,
Section 11.1.1</a>. The syntax for declaring such restrictions is the same as
declaring restrictions using a certain set of architectures without
architecture wildcards. For example:
</p>
<pre>
Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
</pre>
<p>
is equivalent to <samp>foo</samp> on architectures using the Linux kernel and
any cpu, <samp>bar</samp> on architectures using any kernel and an i386 cpu,
and <samp>baz</samp> on any architecture using a kernel other than Linux.
</p>
<p>
Note that the binary package relationship fields such as <samp>Depends</samp>
appear in one of the binary package sections of the control file, whereas the
build-time relationships such as <samp>Build-Depends</samp> appear in the
source package section of the control file (which is the first section).
</p>
<hr>
<h2><a name="s-binarydeps"></a>7.2 Binary Dependencies - <samp>Depends</samp>, <samp>Recommends</samp>, <samp>Suggests</samp>, <samp>Enhances</samp>, <samp>Pre-Depends</samp></h2>
<p>
Packages can declare in their control file that they have certain relationships
to other packages - for example, that they may not be installed at the same
time as certain other packages, and/or that they depend on the presence of
others.
</p>
<p>
This is done using the <samp>Depends</samp>, <samp>Pre-Depends</samp>,
<samp>Recommends</samp>, <samp>Suggests</samp>, <samp>Enhances</samp>,
<samp>Breaks</samp> and <samp>Conflicts</samp> control fields.
<samp>Breaks</samp> is described in <a href="#s-breaks">Packages which break
other packages - <samp>Breaks</samp>, Section 7.3</a>, and
<samp>Conflicts</samp> is described in <a href="#s-conflicts">Conflicting
binary packages - <samp>Conflicts</samp>, Section 7.4</a>. The rest are
described below.
</p>
<p>
These seven fields are used to declare a dependency relationship by one package
on another. Except for <samp>Enhances</samp> and <samp>Breaks</samp>, they
appear in the depending (binary) package's control file.
(<samp>Enhances</samp> appears in the recommending package's control file, and
<samp>Breaks</samp> appears in the version of depended-on package which causes
the named package to break).
</p>
<p>
A <samp>Depends</samp> field takes effect <em>only</em> when a package is to be
configured. It does not prevent a package being on the system in an
unconfigured state while its dependencies are unsatisfied, and it is possible
to replace a package whose dependencies are satisfied and which is properly
installed with a different version whose dependencies are not and cannot be
satisfied; when this is done the depending package will be left unconfigured
(since attempts to configure it will give errors) and will not function
properly. If it is necessary, a <samp>Pre-Depends</samp> field can be used,
which has a partial effect even when a package is being unpacked, as explained
in detail below. (The other three dependency fields, <samp>Recommends</samp>,
<samp>Suggests</samp> and <samp>Enhances</samp>, are only used by the various
front-ends to <code>dpkg</code> such as <code>apt-get</code>,
<code>aptitude</code>, and <code>dselect</code>.)
</p>
<p>
Since <samp>Depends</samp> only places requirements on the order in which
packages are configured, packages in an installation run are usually all
unpacked first and all configured later. [<a href="footnotes.html#f51"
name="fr51">51</a>]
</p>
<p>
If there is a circular dependency among packages being installed or removed,
installation or removal order honoring the dependency order is impossible,
requiring the dependency loop be broken at some point and the dependency
requirements violated for at least one package. Packages involved in circular
dependencies may not be able to rely on their dependencies being configured
before they themselves are configured, depending on which side of the break of
the circular dependency loop they happen to be on. If one of the packages in
the loop has no <code>postinst</code> script, then the cycle will be broken at
that package; this ensures that all <code>postinst</code> scripts are run with
their dependencies properly configured if this is possible. Otherwise the
breaking point is arbitrary. Packages should therefore avoid circular
dependencies where possible, particularly if they have <code>postinst</code>
scripts.
</p>
<p>
The meaning of the five dependency fields is as follows:
</p>
<dl>
<dt><samp>Depends</samp></dt>
<dd>
<p>
This declares an absolute dependency. A package will not be configured unless
all of the packages listed in its <samp>Depends</samp> field have been
correctly configured (unless there is a circular dependency as described
above).
</p>
<p>
The <samp>Depends</samp> field should be used if the depended-on package is
required for the depending package to provide a significant amount of
functionality.
</p>
<p>
The <samp>Depends</samp> field should also be used if the <code>postinst</code>
or <code>prerm</code> scripts require the depended-on package to be unpacked or
configured in order to run. In the case of <samp>postinst configure</samp>,
the depended-on packages will be unpacked and configured first. (If both
packages are involved in a dependency loop, this might not work as expected;
see the explanation a few paragraphs back.) In the case of <code>prerm</code>
or other <code>postinst</code> actions, the package dependencies will normally
be at least unpacked, but they may be only "Half-Installed" if a
previous upgrade of the dependency failed.
</p>
<p>
Finally, the <samp>Depends</samp> field should be used if the depended-on
package is needed by the <code>postrm</code> script to fully clean up after the
package removal. There is no guarantee that package dependencies will be
available when <code>postrm</code> is run, but the depended-on package is more
likely to be available if the package declares a dependency (particularly in
the case of <samp>postrm remove</samp>). The <code>postrm</code> script must
gracefully skip actions that require a dependency if that dependency isn't
available.
</p>
</dd>
</dl>
<dl>
<dt><samp>Recommends</samp></dt>
<dd>
<p>
This declares a strong, but not absolute, dependency.
</p>
<p>
The <samp>Recommends</samp> field should list packages that would be found
together with this one in all but unusual installations.
</p>
</dd>
</dl>
<dl>
<dt><samp>Suggests</samp></dt>
<dd>
<p>
This is used to declare that one package may be more useful with one or more
others. Using this field tells the packaging system and the user that the
listed packages are related to this one and can perhaps enhance its usefulness,
but that installing this one without them is perfectly reasonable.
</p>
</dd>
</dl>
<dl>
<dt><samp>Enhances</samp></dt>
<dd>
<p>
This field is similar to Suggests but works in the opposite direction. It is
used to declare that a package can enhance the functionality of another
package.
</p>
</dd>
</dl>
<dl>
<dt><samp>Pre-Depends</samp></dt>
<dd>
<p>
This field is like <samp>Depends</samp>, except that it also forces
<code>dpkg</code> to complete installation of the packages named before even
starting the installation of the package which declares the pre-dependency, as
follows:
</p>
<p>
When a package declaring a pre-dependency is about to be <em>unpacked</em> the
pre-dependency can be satisfied if the depended-on package is either fully
configured, <em>or even if</em> the depended-on package(s) are only unpacked or
in the "Half-Configured" state, provided that they have been
configured correctly at some point in the past (and not removed or partially
removed since). In this case, both the previously-configured and currently
unpacked or "Half-Configured" versions must satisfy any version
clause in the <samp>Pre-Depends</samp> field.
</p>
<p>
When the package declaring a pre-dependency is about to be <em>configured</em>,
the pre-dependency will be treated as a normal <samp>Depends</samp>. It will
be considered satisfied only if the depended-on package has been correctly
configured. However, unlike with <samp>Depends</samp>,
<samp>Pre-Depends</samp> does not permit circular dependencies to be broken.
If a circular dependency is encountered while attempting to honor
<samp>Pre-Depends</samp>, the installation will be aborted.
</p>
<p>
<samp>Pre-Depends</samp> are also required if the <code>preinst</code> script
depends on the named package. It is best to avoid this situation if possible.
</p>
<p>
<samp>Pre-Depends</samp> should be used sparingly, preferably only by packages
whose premature upgrade or installation would hamper the ability of the system
to continue with any upgrade that might be in progress.
</p>
<p>
You should not specify a <samp>Pre-Depends</samp> entry for a package before
this has been discussed on the <samp>debian-devel</samp> mailing list and a
consensus about doing that has been reached. See <a
href="ch-binary.html#s-dependencies">Dependencies, Section 3.5</a>.
</p>
</dd>
</dl>
<p>
When selecting which level of dependency to use you should consider how
important the depended-on package is to the functionality of the one declaring
the dependency. Some packages are composed of components of varying degrees of
importance. Such a package should list using <samp>Depends</samp> the
package(s) which are required by the more important components. The other
components' requirements may be mentioned as Suggestions or Recommendations, as
appropriate to the components' relative importance.
</p>
<hr>
<h2><a name="s-breaks"></a>7.3 Packages which break other packages - <samp>Breaks</samp></h2>
<p>
When one binary package declares that it breaks another, <code>dpkg</code> will
refuse to allow the package which declares <samp>Breaks</samp> to be unpacked
unless the broken package is deconfigured first, and it will refuse to allow
the broken package to be reconfigured.
</p>
<p>
A package will not be regarded as causing breakage merely because its
configuration files are still installed; it must be at least
"Half-Installed".
</p>
<p>
A special exception is made for packages which declare that they break their
own package name or a virtual package which they provide (see below): this does
not count as a real breakage.
</p>
<p>
Normally a <samp>Breaks</samp> entry will have an "earlier than"
version clause; such a <samp>Breaks</samp> is introduced in the version of an
(implicit or explicit) dependency which violates an assumption or reveals a bug
in earlier versions of the broken package, or which takes over a file from
earlier versions of the package named in <samp>Breaks</samp>. This use of
<samp>Breaks</samp> will inform higher-level package management tools that the
broken package must be upgraded before the new one.
</p>
<p>
If the breaking package also overwrites some files from the older package, it
should use <samp>Replaces</samp> to ensure this goes smoothly. See <a
href="#s-replaces">Overwriting files and replacing packages -
<samp>Replaces</samp>, Section 7.6</a> for a full discussion of taking over
files from other packages, including how to use <samp>Breaks</samp> in those
cases.
</p>
<p>
Many of the cases where <samp>Breaks</samp> should be used were previously
handled with <samp>Conflicts</samp> because <samp>Breaks</samp> did not yet
exist. Many <samp>Conflicts</samp> fields should now be <samp>Breaks</samp>.
See <a href="#s-conflicts">Conflicting binary packages -
<samp>Conflicts</samp>, Section 7.4</a> for more information about the
differences.
</p>
<hr>
<h2><a name="s-conflicts"></a>7.4 Conflicting binary packages - <samp>Conflicts</samp></h2>
<p>
When one binary package declares a conflict with another using a
<samp>Conflicts</samp> field, <code>dpkg</code> will refuse to allow them to be
unpacked on the system at the same time. This is a stronger restriction than
<samp>Breaks</samp>, which prevents the broken package from being configured
while the breaking package is in the "Unpacked" state but allows both
packages to be unpacked at the same time.
</p>
<p>
If one package is to be unpacked, the other must be removed first. If the
package being unpacked is marked as replacing (see <a
href="#s-replaces">Overwriting files and replacing packages -
<samp>Replaces</samp>, Section 7.6</a>, but note that <samp>Breaks</samp>
should normally be used in this case) the one on the system, or the one on the
system is marked as deselected, or both packages are marked
<samp>Essential</samp>, then <code>dpkg</code> will automatically remove the
package which is causing the conflict. Otherwise, it will halt the
installation of the new package with an error. This mechanism is specifically
designed to produce an error when the installed package is
<samp>Essential</samp>, but the new package is not.
</p>
<p>
A package will not cause a conflict merely because its configuration files are
still installed; it must be at least "Half-Installed".
</p>
<p>
A special exception is made for packages which declare a conflict with their
own package name, or with a virtual package which they provide (see below):
this does not prevent their installation, and allows a package to conflict with
others providing a replacement for it. You use this feature when you want the
package in question to be the only package providing some feature.
</p>
<p>
Normally, <samp>Breaks</samp> should be used instead of <samp>Conflicts</samp>
since <samp>Conflicts</samp> imposes a stronger restriction on the ordering of
package installation or upgrade and can make it more difficult for the package
manager to find a correct solution to an upgrade or installation problem.
<samp>Breaks</samp> should be used
</p>
<ul>
<li>
<p>
when moving a file from one package to another (see <a
href="#s-replaces">Overwriting files and replacing packages -
<samp>Replaces</samp>, Section 7.6</a>),
</p>
</li>
</ul>
<ul>
<li>
<p>
when splitting a package (a special case of the previous one), or
</p>
</li>
</ul>
<ul>
<li>
<p>
when the breaking package exposes a bug in or interacts badly with particular
versions of the broken package.
</p>
</li>
</ul>
<p>
<samp>Conflicts</samp> should be used
</p>
<ul>
<li>
<p>
when two packages provide the same file and will continue to do so,
</p>
</li>
</ul>
<ul>
<li>
<p>
in conjunction with <samp>Provides</samp> when only one package providing a
given virtual facility may be unpacked at a time (see <a
href="#s-virtual">Virtual packages - <samp>Provides</samp>, Section 7.5</a>),
</p>
</li>
</ul>
<ul>
<li>
<p>
in other cases where one must prevent simultaneous installation of two packages
for reasons that are ongoing (not fixed in a later version of one of the
packages) or that must prevent both packages from being unpacked at the same
time, not just configured.
</p>
</li>
</ul>
<p>
Be aware that adding <samp>Conflicts</samp> is normally not the best solution
when two packages provide the same files. Depending on the reason for that
conflict, using alternatives or renaming the files is often a better approach.
See, for example, <a href="ch-files.html#s-binaries">Binaries, Section
10.1</a>.
</p>
<p>
Neither <samp>Breaks</samp> nor <samp>Conflicts</samp> should be used unless
two packages cannot be installed at the same time or installing them both
causes one of them to be broken or unusable. Having similar functionality or
performing the same tasks as another package is not sufficient reason to
declare <samp>Breaks</samp> or <samp>Conflicts</samp> with that package.
</p>
<p>
A <samp>Conflicts</samp> entry may have an "earlier than" version
clause if the reason for the conflict is corrected in a later version of one of
the packages. However, normally the presence of an "earlier than"
version clause is a sign that <samp>Breaks</samp> should have been used
instead. An "earlier than" version clause in <samp>Conflicts</samp>
prevents <code>dpkg</code> from upgrading or installing the package which
declares such a conflict until the upgrade or removal of the conflicted-with
package has been completed, which is a strong restriction.
</p>
<hr>
<h2><a name="s-virtual"></a>7.5 Virtual packages - <samp>Provides</samp></h2>
<p>
As well as the names of actual ("concrete") packages, the package
relationship fields <samp>Depends</samp>, <samp>Recommends</samp>,
<samp>Suggests</samp>, <samp>Enhances</samp>, <samp>Pre-Depends</samp>,
<samp>Breaks</samp>, <samp>Conflicts</samp>, <samp>Build-Depends</samp>,
<samp>Build-Depends-Indep</samp>, <samp>Build-Conflicts</samp> and
<samp>Build-Conflicts-Indep</samp> may mention "virtual packages".
</p>
<p>
A <em>virtual package</em> is one which appears in the <samp>Provides</samp>
control field of another package. The effect is as if the package(s) which
provide a particular virtual package name had been listed by name everywhere
the virtual package name appears. (See also <a
href="ch-binary.html#s-virtual_pkg">Virtual packages, Section 3.6</a>)
</p>
<p>
If there are both concrete and virtual packages of the same name, then the
dependency may be satisfied (or the conflict caused) by either the concrete
package with the name in question or any other concrete package which provides
the virtual package with the name in question. This is so that, for example,
supposing we have
</p>
<pre>
Package: foo
Depends: bar
</pre>
<p>
and someone else releases an enhanced version of the <samp>bar</samp> package
they can say:
</p>
<pre>
Package: bar-plus
Provides: bar
</pre>
<p>
and the <samp>bar-plus</samp> package will now also satisfy the dependency for
the <samp>foo</samp> package.
</p>
<p>
If a relationship field has a version number attached, only real packages will
be considered to see whether the relationship is satisfied (or the prohibition
violated, for a conflict or breakage). In other words, if a version number is
specified, this is a request to ignore all <samp>Provides</samp> for that
package name and consider only real packages. The package manager will assume
that a package providing that virtual package is not of the "right"
version. A <samp>Provides</samp> field may not contain version numbers, and
the version number of the concrete package which provides a particular virtual
package will not be considered when considering a dependency on or conflict
with the virtual package name.[<a href="footnotes.html#f52" name="fr52">52</a>]
</p>
<p>
To specify which of a set of real packages should be the default to satisfy a
particular dependency on a virtual package, list the real package as an
alternative before the virtual one.
</p>
<p>
If the virtual package represents a facility that can only be provided by one
real package at a time, such as the <code>mail-transport-agent</code> virtual
package that requires installation of a binary that would conflict with all
other providers of that virtual package (see <a
href="ch-customized-programs.html#s-mail-transport-agents">Mail transport,
delivery and user agents, Section 11.6</a>), all packages providing that
virtual package should also declare a conflict with it using
<samp>Conflicts</samp>. This will ensure that at most one provider of that
virtual package is unpacked or installed at a time.
</p>
<hr>
<h2><a name="s-replaces"></a>7.6 Overwriting files and replacing packages - <samp>Replaces</samp></h2>
<p>
Packages can declare in their control file that they should overwrite files in
certain other packages, or completely replace other packages. The
<samp>Replaces</samp> control field has these two distinct purposes.
</p>
<hr>
<h3><a name="s7.6.1"></a>7.6.1 Overwriting files in other packages</h3>
<p>
It is usually an error for a package to contain files which are on the system
in another package. However, if the overwriting package declares that it
<samp>Replaces</samp> the one containing the file being overwritten, then
<code>dpkg</code> will replace the file from the old package with that from the
new. The file will no longer be listed as "owned" by the old package
and will be taken over by the new package. Normally, <samp>Breaks</samp>
should be used in conjunction with <samp>Replaces</samp>.[<a
href="footnotes.html#f53" name="fr53">53</a>]
</p>
<p>
For example, if a package <code>foo</code> is split into <code>foo</code> and
<code>foo-data</code> starting at version 1.2-3, <code>foo-data</code> would
have the fields
</p>
<pre>
Replaces: foo (<< 1.2-3)
Breaks: foo (<< 1.2-3)
</pre>
<p>
in its control file. The new version of the package <code>foo</code> would
normally have the field
</p>
<pre>
Depends: foo-data (>= 1.2-3)
</pre>
<p>
(or possibly <samp>Recommends</samp> or even <samp>Suggests</samp> if the files
moved into <code>foo-data</code> are not required for normal operation).
</p>
<p>
If a package is completely replaced in this way, so that <code>dpkg</code> does
not know of any files it still contains, it is considered to have
"disappeared". It will be marked as not wanted on the system
(selected for removal) and not installed. Any <samp>conffile</samp>s details
noted for the package will be ignored, as they will have been taken over by the
overwriting package. The package's <code>postrm</code> script will be run with
a special argument to allow the package to do any final cleanup required. See
<a href="ch-maintainerscripts.html#s-mscriptsinstact">Summary of ways
maintainer scripts are called, Section 6.5</a>. [<a href="footnotes.html#f54"
name="fr54">54</a>]
</p>
<p>
For this usage of <samp>Replaces</samp>, virtual packages (see <a
href="#s-virtual">Virtual packages - <samp>Provides</samp>, Section 7.5</a>)
are not considered when looking at a <samp>Replaces</samp> field. The packages
declared as being replaced must be mentioned by their real names.
</p>
<p>
This usage of <samp>Replaces</samp> only takes effect when both packages are at
least partially on the system at once. It is not relevant if the packages
conflict unless the conflict has been overridden.
</p>
<hr>
<h3><a name="s7.6.2"></a>7.6.2 Replacing whole packages, forcing their removal</h3>
<p>
Second, <samp>Replaces</samp> allows the packaging system to resolve which
package should be removed when there is a conflict (see <a
href="#s-conflicts">Conflicting binary packages - <samp>Conflicts</samp>,
Section 7.4</a>). This usage only takes effect when the two packages
<em>do</em> conflict, so that the two usages of this field do not interfere
with each other.
</p>
<p>
In this situation, the package declared as being replaced can be a virtual
package, so for example, all mail transport agents (MTAs) would have the
following fields in their control files:
</p>
<pre>
Provides: mail-transport-agent
Conflicts: mail-transport-agent
Replaces: mail-transport-agent
</pre>
<p>
ensuring that only one MTA can be unpacked at any one time. See <a
href="#s-virtual">Virtual packages - <samp>Provides</samp>, Section 7.5</a> for
more information about this example.
</p>
<hr>
<h2><a name="s-sourcebinarydeps"></a>7.7 Relationships between source and binary packages - <samp>Build-Depends</samp>, <samp>Build-Depends-Indep</samp>, <samp>Build-Conflicts</samp>, <samp>Build-Conflicts-Indep</samp></h2>
<p>
Source packages that require certain binary packages to be installed or absent
at the time of building the package can declare relationships to those binary
packages.
</p>
<p>
This is done using the <samp>Build-Depends</samp>,
<samp>Build-Depends-Indep</samp>, <samp>Build-Conflicts</samp> and
<samp>Build-Conflicts-Indep</samp> control fields.
</p>
<p>
Build-dependencies on "build-essential" binary packages can be
omitted. Please see <a href="ch-source.html#s-pkg-relations">Package
relationships, Section 4.2</a> for more information.
</p>
<p>
The dependencies and conflicts they define must be satisfied (as defined
earlier for binary packages) in order to invoke the targets in
<samp>debian/rules</samp>, as follows:[<a href="footnotes.html#f55"
name="fr55">55</a>]
</p>
<dl>
<dt><samp>clean</samp>, <samp>build-arch</samp>, and <samp>binary-arch</samp></dt>
<dd>
<p>
Only the <samp>Build-Depends</samp> and <samp>Build-Conflicts</samp> fields
must be satisfied when these targets are invoked.
</p>
</dd>
</dl>
<dl>
<dt><samp>build</samp>, <samp>build-indep</samp>, <samp>binary</samp>, and <samp>binary-indep</samp></dt>
<dd>
<p>
The <samp>Build-Depends</samp>, <samp>Build-Conflicts</samp>,
<samp>Build-Depends-Indep</samp>, and <samp>Build-Conflicts-Indep</samp> fields
must be satisfied when these targets are invoked.
</p>
</dd>
</dl>
<hr>
<p>
[ <a href="ch-maintainerscripts.html">previous</a> ]
[ <a href="index.html#contents">Contents</a> ]
[ <a href="ch-scope.html">1</a> ]
[ <a href="ch-archive.html">2</a> ]
[ <a href="ch-binary.html">3</a> ]
[ <a href="ch-source.html">4</a> ]
[ <a href="ch-controlfields.html">5</a> ]
[ <a href="ch-maintainerscripts.html">6</a> ]
[ 7 ]
[ <a href="ch-sharedlibs.html">8</a> ]
[ <a href="ch-opersys.html">9</a> ]
[ <a href="ch-files.html">10</a> ]
[ <a href="ch-customized-programs.html">11</a> ]
[ <a href="ch-docs.html">12</a> ]
[ <a href="ap-pkg-scope.html">A</a> ]
[ <a href="ap-pkg-binarypkg.html">B</a> ]
[ <a href="ap-pkg-sourcepkg.html">C</a> ]
[ <a href="ap-pkg-controlfields.html">D</a> ]
[ <a href="ap-pkg-conffiles.html">E</a> ]
[ <a href="ap-pkg-alternatives.html">F</a> ]
[ <a href="ap-pkg-diversions.html">G</a> ]
[ <a href="ch-sharedlibs.html">next</a> ]
</p>
<hr>
<p>
Debian Policy Manual
</p>
<address>
version 3.9.3.1, 2012-03-04<br>
<br>
<a href="ch-scope.html#s-authors">The Debian Policy Mailing List</a><br>
<br>
</address>
<hr>
</body>
</html>
|