From c860a39ea13f7d552fc940a546b01be70c09b3a0 Mon Sep 17 00:00:00 2001 From: he Date: Sun, 1 Jun 2008 14:28:18 +0000 Subject: [PATCH] Replace abused tags with tags. git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@5196 313b444b-1b9f-4f58-a734-7bb04f332e8d --- best-pkging-practices.dbk | 6 +- debian/changelog | 6 +- developer-duties.dbk | 4 +- new-maintainer.dbk | 4 +- pkgs.dbk | 161 +++++++++++++++--------------- resources.dbk | 202 +++++++++++++++++++------------------- tools.dbk | 4 +- 7 files changed, 197 insertions(+), 190 deletions(-) diff --git a/best-pkging-practices.dbk b/best-pkging-practices.dbk index 4bf1bf3..0376b3a 100644 --- a/best-pkging-practices.dbk +++ b/best-pkging-practices.dbk @@ -789,7 +789,7 @@ If you don't do so, the whole template will not be translated as long as a translator will send you an update. -To unfuzzy translations, you can proceed the +To unfuzzy translations, you can proceed the following way: @@ -1716,8 +1716,8 @@ Some debug packages may contain an entire special debugging build of a library or other binary, but most of them can save space and build time by instead containing separated debugging symbols that gdb can find and load on the fly when debugging a program or library. The convention in Debian is to keep these -symbols in /usr/lib/debug/path, where -path is the path to the executable or library. For +symbols in /usr/lib/debug/path, where +path is the path to the executable or library. For example, debugging symbols for /usr/bin/foo go in /usr/lib/debug/usr/bin/foo, and debugging symbols for /usr/lib/libfoo.so.1 go in diff --git a/debian/changelog b/debian/changelog index 17e48c1..7b3884c 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,5 +1,6 @@ developers-reference (3.4.0) UNRELEASED; urgency=low + [ Lucas Nussbaum ] * Update Vcs-* fields after DDP's SVN restructuring. Closes: #483428. * Fix conditions for updates from unstable to testing. Closes: #470754. * linda has been removed. Remove section A.2.2. Closes: #483242. @@ -12,7 +13,10 @@ developers-reference (3.4.0) UNRELEASED; urgency=low * README.contrib: document that short lines are preferred. Closes: #278267. - -- Lucas Nussbaum Fri, 30 May 2008 09:00:07 +0200 + [ Marc 'HE' Brockschmidt ] + * Replace abused tags with tags. + + -- Marc 'HE' Brockschmidt Sun, 01 Jun 2008 16:25:19 +0200 developers-reference (3.3.9) unstable; urgency=low diff --git a/developer-duties.dbk b/developer-duties.dbk index 2e501f3..5b7f73d 100644 --- a/developer-duties.dbk +++ b/developer-duties.dbk @@ -160,8 +160,8 @@ upstream sources. Generally you should deal with bug reports on your packages as described in . However, there's a special category of bugs that you need to take care of — the so-called release-critical bugs (RC -bugs). All bug reports that have severity critical, -grave or serious are considered to +bugs). All bug reports that have severity critical, +grave or serious are considered to have an impact on whether the package can be released in the next stable release of Debian. These bugs can delay the Debian release and/or can justify the removal of a package at freeze time. That's why these bugs need to be diff --git a/new-maintainer.dbk b/new-maintainer.dbk index 3f4a077..5ff7ccc 100644 --- a/new-maintainer.dbk +++ b/new-maintainer.dbk @@ -18,7 +18,7 @@ developer so that your work can be incorporated into the Project? Firstly, subscribe to &email-debian-devel; if you haven't already. Send the word subscribe in the -Subject of an email to +Subject of an email to &email-debian-devel-req;. In case of problems, contact the list administrator at &email-listmaster;. More information on available mailing lists can be found in . @@ -196,7 +196,7 @@ can make special arrangements. To apply as a new maintainer, you need an existing Debian Developer to support -your application (an advocate). After you have +your application (an advocate). After you have contributed to Debian for a while, and you want to apply to become a registered developer, an existing developer with whom you have worked over the past months has to express their belief that you can contribute to Debian successfully. diff --git a/pkgs.dbk b/pkgs.dbk index 15cb2f0..d2cd31a 100644 --- a/pkgs.dbk +++ b/pkgs.dbk @@ -31,7 +31,7 @@ current URL where it can be downloaded from. You should set the subject of the bug to ``ITP: foo -- short description'', substituting the name of the new package for foo. The severity of the bug report -must be set to wishlist. If you feel it's necessary, send +must be set to wishlist. If you feel it's necessary, send a copy to &email-debian-devel; by putting the address in the X-Debbugs-CC: header of the message (no, don't use CC:, because that way the message's subject won't indicate @@ -110,7 +110,7 @@ for native packages. The debian/changelog file conforms to a certain structure, with a number of different fields. One field of note, the -distribution, is described in distribution, is described in . More information about the structure of this file can be found in the Debian Policy section titled debian/changelog. @@ -206,7 +206,7 @@ There are two types of Debian source packages: -the so-called native packages, where there is no +the so-called native packages, where there is no distinction between the original sources and the patches applied for Debian @@ -271,7 +271,7 @@ The package build process extracts this information from the first line of the There are several possible values for this field: `stable', `unstable', `testing-proposed-updates' and `experimental'. Normally, packages are uploaded -into unstable. +into unstable. Actually, there are two other possible distributions: `stable-security' and @@ -283,17 +283,17 @@ It is not possible to upload a package into several distributions at the same time.
-Special case: uploads to the <emphasis>stable</emphasis> distribution +Special case: uploads to the <literal>stable</literal> distribution -Uploading to stable means that the package will transfered -to the p-u-new-queue for review by the stable release -managers, and if approved will be installed in +Uploading to stable means that the package will transfered +to the proposed-updates-new-queue for review by the stable +release managers, and if approved will be installed in stable-proposed-updates directory of the Debian archive. -From there, it will be included in stable with the next +From there, it will be included in stable with the next point release. -Extra care should be taken when uploading to stable. +Extra care should be taken when uploading to stable. Basically, a package should only be uploaded to stable if one of the following happens: @@ -315,7 +315,7 @@ a released architecture lacks the package -In the past, uploads to stable were used to address +In the past, uploads to stable were used to address security problems as well. However, this practice is deprecated, as uploads used for Debian security advisories are automatically copied to the appropriate proposed-updates archive when the advisory is released. @@ -327,10 +327,10 @@ Changing anything else in the package that isn't important is discouraged, because even trivial fixes can cause bugs later on. -Packages uploaded to stable need to be compiled on systems -running stable, so that their dependencies are limited to -the libraries (and other packages) available in stable; -for example, a package uploaded to stable that depends on +Packages uploaded to stable need to be compiled on systems +running stable, so that their dependencies are limited to +the libraries (and other packages) available in stable; +for example, a package uploaded to stable that depends on a library package that only exists in unstable will be rejected. Making changes to dependencies of other packages (by messing with Provides or shlibs files), possibly making those other @@ -338,23 +338,23 @@ packages uninstallable, is strongly discouraged. The Release Team (which can be reached at -&email-debian-release;) will regularly evaluate the uploads To -stable-proposed-updates and decide if your package can be -included in stable. Please be clear (and verbose, if +&email-debian-release;) will regularly evaluate the uploads to +stable-proposed-updates and decide if your package can be +included in stable. Please be clear (and verbose, if necessary) in your changelog entries for uploads to -stable, because otherwise the package won't be considered +stable, because otherwise the package won't be considered for inclusion. It's best practice to speak with the stable release manager before uploading to -stable/stable-proposed-updates, so +stable/stable-proposed-updates, so that the uploaded package fits the needs of the next point release.
-Special case: uploads to <emphasis>testing/testing-proposed-updates</emphasis> +Special case: uploads to <literal>testing/testing-proposed-updates</literal> Please see the information in the testing section for details. @@ -395,9 +395,10 @@ the Debian package .
Delayed uploads -Delayed uploads are done for the moment via the delayed queue at gluck. The -upload-directory is gluck:~tfheen/DELAYED/[012345678]-day. -0-day is uploaded multiple times per day to ftp-master. +Delayed uploads are done for the moment via the delayed queue at gluck +. The upload-directory is +gluck:~tfheen/DELAYED/[012345678]-day. 0-day is uploaded +multiple times per day to &ftp-master-host;. With a fairly recent dput, this section @@ -409,11 +410,12 @@ fqdn = gluck.debian.org incoming = ~tfheen -in ~/.dput.cf should work fine for uploading to the DELAYED queue. +in ~/.dput.cf should work fine for uploading to the +DELAYED queue. Note: Since this upload queue goes to -ftp-master, the prescription found in &ftp-master-host;, the prescription found in applies here as well.
@@ -433,8 +435,8 @@ linkend="bug-security"/> .
Other upload queues -The scp queues on ftp-master, and security are mostly unusable due to the login -restrictions on those hosts. +The scp queues on &ftp-master-host;, and security are mostly +unusable due to the login restrictions on those hosts. The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are currently @@ -495,13 +497,13 @@ actually just hints. The archive maintainers keep track of the canonical sections and priorities for -packages in the override file. If there is a disparity -between the override file and the package's fields as +packages in the override file. If there is a disparity +between the override file and the package's fields as indicated in debian/control, then you will receive an email noting the divergence when the package is installed into the archive. You can either correct your debian/control file for your -next upload, or else you may wish to make a change in the override -file. +next upload, or else you may wish to make a change in the override +file. To alter the actual section that a package is put in, you need to first make @@ -512,7 +514,7 @@ that the section or priority for your package be changed from the old section or priority to the new one. Be sure to explain your reasoning. -For more information about override files, see +For more information about override files, see dpkg-scanpackages 1 and . @@ -596,7 +598,7 @@ Porters frequently use this acronym. Once you've dealt with a bug report (e.g. fixed it), mark it as -done (close it) by sending an explanation message to +done (close it) by sending an explanation message to 123-done@&bugs-host;. If you're fixing a bug by changing and uploading the package, you can automate bug closing as described in . @@ -719,7 +721,7 @@ several developers working on the same package. -Once a corrected package is available in the unstable +Once a corrected package is available in the unstable distribution, you can close the bug. This can be done automatically, read . @@ -1059,7 +1061,7 @@ Target the right distribution in your debian/changelog. For stable this is stable-security and for testing this is testing-security, and for the previous stable release, this is oldstable-security. Do not target -distribution-proposed-updates or +distribution-proposed-updates or stable! @@ -1086,9 +1088,9 @@ Make sure the version number is proper. It must be greater than the current package, but less than package versions in later distributions. If in doubt, test it with dpkg --compare-versions. Be careful not to re-use a version number that you have already used for a previous upload. For -testing, there must be a higher version in -unstable. If there is none yet (for example, if -testing and unstable have the same +testing, there must be a higher version in +unstable. If there is none yet (for example, if +testing and unstable have the same version) you must upload a new version to unstable first. @@ -1166,7 +1168,8 @@ problems that cannot be disclosed yet. If a member of the security team accepts a package, it will be installed on security.debian.org as well as proposed for the proper -distribution-proposed-updates on ftp-master. +distribution-proposed-updates +on &ftp-master-host;.
@@ -1203,7 +1206,7 @@ automatically. If it does not, then contact the ftpmasters in order to understand what happened. -If, on the other hand, you need to change the subsection +If, on the other hand, you need to change the subsection of one of your packages (e.g., ``devel'', ``admin''), the procedure is slightly different. Correct the subsection as found in the control file of the package, and re-upload that. Also, you'll need to get the override file updated, as @@ -1219,11 +1222,11 @@ old compatibility library which is no longer required), you need to file a bug against ftp.debian.org asking that the package be removed; as all bugs, this bug should normally have normal severity. Make sure you indicate which distribution the package should be removed from. Normally, you -can only have packages removed from unstable and -experimental. Packages are not removed from -testing directly. Rather, they will be removed +can only have packages removed from unstable and +experimental. Packages are not removed from +testing directly. Rather, they will be removed automatically after the package has been removed from -unstable and no package in testing +unstable and no package in testing depends on it. @@ -1277,7 +1280,7 @@ In the past, it was possible to remove packages from incoming system, this is no longer possible. Instead, you have to upload a new revision of your package with a higher version than the package you want to replace. Both versions will be installed in the archive but only the higher -version will actually be available in unstable since the +version will actually be available in unstable since the previous version will immediately be replaced by the higher. However, if you do proper testing of your packages, the need to replace a package should not occur too often anyway. @@ -1323,7 +1326,7 @@ role="package">wnpp. The bug report should be titled O: package -- short description indicating that the package is now orphaned. The severity of the bug should be set to -normal; if the package has a priority of standard or +normal; if the package has a priority of standard or higher, it should be set to important. If you feel it's necessary, send a copy to &email-debian-devel; by putting the address in the X-Debbugs-CC: header of the message (no, don't use CC:, because that way the @@ -1335,7 +1338,7 @@ for the moment, then you should instead submit a bug against wnpp and title it RFA: package -- short description. RFA stands for -Request For Adoption. +Request For Adoption. More information is on the WNPP @@ -1395,7 +1398,7 @@ Porting is the act of building Debian packages for architectures that are different from the original architecture of the package maintainer's binary package. It is a unique and essential activity. In fact, porters do most of the actual compiling of Debian packages. For instance, for a single -i386 binary package, there must be a recompile for each +i386 binary package, there must be a recompile for each architecture, which amounts to &number-of-arches; more builds.
@@ -1665,7 +1668,7 @@ linkend="tools-porting"/> . The buildd system is used as a distributed, client-server build distribution system. It is usually used in -conjunction with auto-builders, which are ``slave'' hosts +conjunction with build daemons, which are ``slave'' hosts which simply check out and attempt to auto-build packages which need to be ported. There is also an email interface to the system, which allows porters to ``check out'' a source package (usually one which cannot yet be auto-built) @@ -2051,7 +2054,7 @@ There are two new terms used throughout this section: ``binary-only NMU'' and throughout this document. Both binary-only and source NMUs are similar, since they involve an upload of a package by a developer who is not the official maintainer of that package. That is why it's a -non-maintainer upload. +non-maintainer upload. A source NMU is an upload of a package by a developer who is not the official @@ -2182,21 +2185,21 @@ below for details.
Updates from unstable -The scripts that update the testing distribution are run +The scripts that update the testing distribution are run each day after the installation of the updated packages; these scripts are -called britney. They generate the -Packages files for the testing +called britney. They generate the +Packages files for the testing distribution, but they do so in an intelligent manner; they try to avoid any inconsistency and to use only non-buggy packages. -The inclusion of a package from unstable is conditional on +The inclusion of a package from unstable is conditional on the following: -The package must have been available in unstable for 2, 5 +The package must have been available in unstable for 2, 5 or 10 days, depending on the urgency (high, medium or low). Please note that the urgency is sticky, meaning that the highest urgency uploaded since the previous testing transition is taken into account. Those delays may be doubled @@ -2206,8 +2209,8 @@ during a freeze, or testing transitions may be switched off altogether; It must not have new release-critical bugs (RC bugs affecting the version -available in unstable, but not affecting the version in -testing); +available in unstable, but not affecting the version in +testing); @@ -2220,14 +2223,14 @@ information; It must not break any dependency of a package which is already available in -testing; +testing; The packages on which it depends must either be available in -testing or they must be accepted into -testing at the same time (and they will be if they fulfill +testing or they must be accepted into +testing at the same time (and they will be if they fulfill all the necessary criteria); @@ -2241,7 +2244,7 @@ is in the devscripts package. This utility can easily be used in a crontab 5 to keep yourself informed of the progression of your packages into -testing. +testing. The update_excuses file does not always give the precise @@ -2251,7 +2254,7 @@ url="&url-testing-maint;">testing web page gives some more information about the usual problems which may be causing such troubles. -Sometimes, some packages never enter testing because the +Sometimes, some packages never enter testing because the set of inter-relationship is too complicated and cannot be sorted out by the scripts. See below for details. @@ -2347,9 +2350,9 @@ maintain glibc or so.) Sometimes, a package is removed to allow another package in: This happens only to allow another package to go in if it's ready in every -other sense. Suppose e.g. that a cannot be installed -with the new version of b; then a may -be removed to allow b in. +other sense. Suppose e.g. that a cannot be installed +with the new version of b; then a may +be removed to allow b in. Of course, there is another reason to remove a package from testing: It's just @@ -2365,8 +2368,8 @@ testing depends on it any more, then it will automatically be removed. circular dependencies A situation which is not handled very well by britney is if package -a depends on the new version of package -b, and vice versa. +a depends on the new version of package +b, and vice versa. An example of this is: @@ -2395,7 +2398,7 @@ An example of this is: -Neither package a nor package b is +Neither package a nor package b is considered for update. @@ -2467,7 +2470,7 @@ url="http://&ftp-master-host;/testing/hints/">. The testing distribution is fed with packages from unstable according to the rules explained above. However, in some cases, it is necessary to upload packages built only for testing. For that, you may want to upload to -testing-proposed-updates. +testing-proposed-updates. Keep in mind that packages uploaded there are not automatically processed, they @@ -2477,8 +2480,8 @@ release managers' eyes, you should read the instructions that they regularly give on &email-debian-devel-announce;. -You should not upload to testing-proposed-updates when you -can update your packages through unstable. If you can't +You should not upload to testing-proposed-updates when you +can update your packages through unstable. If you can't (for example because you have a newer development version in unstable), you may use this facility, but it is recommended that you ask for authorization from the release manager first. Even if a package is frozen, updates through @@ -2488,7 +2491,7 @@ dependencies. Version numbers are usually selected by adding the codename of the testing distribution and a running number, like 1.2sarge1 for the first upload through -testing-proposed-updates of package version 1.2. +testing-proposed-updates of package version 1.2. Please make sure you didn't miss any of these items in your upload: @@ -2497,7 +2500,7 @@ Please make sure you didn't miss any of these items in your upload: Make sure that your package really needs to go through -testing-proposed-updates, and can't go through unstable; +testing-proposed-updates, and can't go through unstable; @@ -2512,21 +2515,21 @@ Make sure that you included an appropriate explanation in the changelog; -Make sure that you've written testing or -testing-proposed-updates into your target distribution; +Make sure that you've written testing or +testing-proposed-updates into your target distribution; Make sure that you've built and tested your package in -testing, not in unstable; +testing, not in unstable; Make sure that your version number is higher than the version in -testing and testing-proposed-updates, -and lower than in unstable; +testing and testing-proposed-updates, +and lower than in unstable; diff --git a/resources.dbk b/resources.dbk index 3648a1e..78aaab7 100644 --- a/resources.dbk +++ b/resources.dbk @@ -132,45 +132,45 @@ community (OFTC) network. The irc.debian.org DNS entry is an alias to irc.oftc.net. -The main channel for Debian in general is #debian. This +The main channel for Debian in general is #debian. This is a large, general-purpose channel where users can find recent news in the -topic and served by bots. #debian is for English -speakers; there are also #debian.de, -#debian-fr, #debian-br and other +topic and served by bots. #debian is for English +speakers; there are also #debian.de, +#debian-fr, #debian-br and other similarly named channels for speakers of other languages. -The main channel for Debian development is #debian-devel. +The main channel for Debian development is #debian-devel. It is a very active channel since usually over 150 people are always logged in. It's a channel for people who work on Debian, it's not a support channel -(there's #debian for that). It is however open to anyone +(there's #debian for that). It is however open to anyone who wants to lurk (and learn). Its topic is commonly full of interesting information for developers. -Since #debian-devel is an open channel, you should not +Since #debian-devel is an open channel, you should not speak there of issues that are discussed in &email-debian-private;. There's another channel for this -purpose, it's called #debian-private and it's protected by +purpose, it's called #debian-private and it's protected by a key. This key is available in the archives of debian-private in master.debian.org:&file-debian-private-archive;, -just zgrep for #debian-private in all +just zgrep for #debian-private in all the files. There are other additional channels dedicated to specific subjects. -#debian-bugs is used for coordinating bug squashing -parties. #debian-boot is used to coordinate the work on -the debian-installer. #debian-doc is occasionally used to +#debian-bugs is used for coordinating bug squashing +parties. #debian-boot is used to coordinate the work on +the debian-installer. #debian-doc is occasionally used to talk about documentation, like the document you are reading. Other channels are dedicated to an architecture or a set of packages: -#debian-kde, #debian-dpkg, -#debian-jr, #debian-edu, -#debian-oo (OpenOffice package) ... +#debian-kde, #debian-dpkg, +#debian-jr, #debian-edu, +#debian-oo (OpenOffice package) ... Some non-English developers' channels exist as well, for example -#debian-devel-fr for French speaking people interested in +#debian-devel-fr for French speaking people interested in Debian's development. @@ -444,14 +444,14 @@ As you can see, the top-level directory contains two directories, dists/ and pool/. The latter is a “pool” in which the packages actually are, and which is handled by the archive maintenance database and the accompanying programs. The former -contains the distributions, stable, -testing and unstable. The +contains the distributions, stable, +testing and unstable. The Packages and Sources files in the distribution subdirectories can reference files in the pool/ directory. The directory tree below each of the distributions is arranged in an identical manner. What we describe below for -stable is equally applicable to the -unstable and testing distributions. +stable is equally applicable to the +unstable and testing distributions. dists/stable contains three directories, namely @@ -472,9 +472,9 @@ installing the Debian distribution on a specific architecture
Sections -The main section of the Debian archive is what makes up +The main section of the Debian archive is what makes up the official &debian-formal; distribution. -The main section is official because it fully complies +The main section is official because it fully complies with all our guidelines. The other two sections do not, to different degrees; as such, they are not officially part of &debian-formal;. @@ -488,13 +488,13 @@ Manual. The DFSG is our definition of “free software.” Check out the Debian Policy Manual for details. -Packages in the contrib section have to comply with the +Packages in the contrib section have to comply with the DFSG, but may fail other requirements. For instance, they may depend on non-free packages. Packages which do not conform to the DFSG are placed in the -non-free section. These packages are not considered as +non-free section. These packages are not considered as part of the Debian distribution, though we support their use, and we provide infrastructure (such as our bug-tracking system and mailing lists) for non-free software packages. @@ -508,21 +508,21 @@ above discussion is just an introduction. The separation of the three sections at the top-level of the archive is important for all people who want to distribute Debian, either via FTP servers on the Internet or on CD-ROMs: by distributing only the -main and contrib sections, one can -avoid any legal risks. Some packages in the non-free +main and contrib sections, one can +avoid any legal risks. Some packages in the non-free section do not allow commercial distribution, for example. On the other hand, a CD-ROM vendor could easily check the individual package -licenses of the packages in non-free and include as many +licenses of the packages in non-free and include as many on the CD-ROMs as it's allowed to. (Since this varies greatly from vendor to vendor, this job can't be done by the Debian developers.) Note that the term section is also used to refer to categories which simplify the organization and browsing of available packages, e.g. -admin, net, -utils etc. Once upon a time, these sections (subsections, +admin, net, +utils etc. Once upon a time, these sections (subsections, rather) existed in the form of subdirectories within the Debian archive. Nowadays, these exist only in the Section header fields of packages. @@ -541,24 +541,24 @@ Atari, Amiga and Macintoshes), MIPS, and PowerPC. The Linux 2.2 kernel supports even more architectures, including ARM and UltraSPARC. Since Linux supports these platforms, Debian decided that it should, too. Therefore, Debian has ports underway; in fact, we also have ports underway to non-Linux -kernels. Aside from i386 (our name for Intel x86), there -is m68k, alpha, -powerpc, sparc, -hurd-i386, arm, -ia64, hppa, -s390, mips, -mipsel and sh as of this writing. - - -&debian-formal; 1.3 is only available as i386. Debian -2.0 shipped for i386 and m68k -architectures. Debian 2.1 ships for the i386, -m68k, alpha, and -sparc architectures. Debian 2.2 added support for the -powerpc and arm architectures. -Debian 3.0 added support of five new architectures: ia64, -hppa, s390, mips -and mipsel. +kernels. Aside from i386 (our name for Intel x86), there +is m68k, alpha, +powerpc, sparc, +hurd-i386, arm, +ia64, hppa, +s390, mips, +mipsel and sh as of this writing. + + +&debian-formal; 1.3 is only available as i386. Debian +2.0 shipped for i386 and m68k +architectures. Debian 2.1 ships for the i386, +m68k, alpha, and +sparc architectures. Debian 2.2 added support for the +powerpc and arm architectures. +Debian 3.0 added support of five new architectures: ia64, +hppa, s390, mips +and mipsel. Information for developers and users about the specific ports are available at @@ -569,8 +569,8 @@ the Debian Ports web pages.
Packages -There are two types of Debian packages, namely source and -binary packages. +There are two types of Debian packages, namely source and +binary packages. Source packages consist of either two or three files: a @@ -582,9 +582,9 @@ or both an .orig.tar.gz and a If a package is developed specially for Debian and is not distributed outside of Debian, there is just one .tar.gz file which contains the sources of the program. If a package is distributed elsewhere too, the -.orig.tar.gz file stores the so-called upstream -source code, that is the source code that's distributed by the -upstream maintainer (often the author of the software). +.orig.tar.gz file stores the so-called upstream +source code, that is the source code that's distributed by the +upstream maintainer (often the author of the software). In this case, the .diff.gz contains the changes made by the Debian maintainer. @@ -599,7 +599,7 @@ about the package (maintainer, version, etc.). Distributions The directory system described in the previous chapter is itself contained -within distribution directories. Each distribution is +within distribution directories. Each distribution is actually contained in the pool directory in the top-level of the Debian archive itself. @@ -621,16 +621,16 @@ compatibility).
Stable, testing, and unstable -There are always distributions called stable (residing in -dists/stable), testing (residing in -dists/testing), and unstable +There are always distributions called stable (residing in +dists/stable), testing (residing in +dists/testing), and unstable (residing in dists/unstable). This reflects the development process of the Debian project. -Active development is done in the unstable distribution -(that's why this distribution is sometimes called the development -distribution). Every Debian developer can update his or her +Active development is done in the unstable distribution +(that's why this distribution is sometimes called the development +distribution). Every Debian developer can update his or her packages in this distribution at any time. Thus, the contents of this distribution change from day to day. Since no special effort is made to make sure everything in this distribution is working properly, it is sometimes @@ -645,42 +645,42 @@ have been installed. See . After a period of development, once the release manager deems fit, the -testing distribution is frozen, meaning that the policies -which control how packages move from unstable to -testing are tightened. Packages which are too buggy are -removed. No changes are allowed into testing except for +testing distribution is frozen, meaning that the policies +which control how packages move from unstable to +testing are tightened. Packages which are too buggy are +removed. No changes are allowed into testing except for bug fixes. After some time has elapsed, depending on progress, the -testing distribution is frozen even further. Details of +testing distribution is frozen even further. Details of the handling of the testing distribution are published by the Release Team on debian-devel-announce. After the open issues are solved to the satisfaction of the Release Team, the distribution is released. Releasing means that -testing is renamed to stable, and a -new copy is created for the new testing, and the previous -stable is renamed to oldstable and +testing is renamed to stable, and a +new copy is created for the new testing, and the previous +stable is renamed to oldstable and stays there until it is finally archived. On archiving, the contents are moved to &archive-host;). This development cycle is based on the assumption that the -unstable distribution becomes stable -after passing a period of being in testing. Even once a +unstable distribution becomes stable +after passing a period of being in testing. Even once a distribution is considered stable, a few bugs inevitably remain — that's why the stable distribution is updated every now and then. However, these updates are tested very carefully and have to be introduced into the archive individually to reduce the risk of introducing new bugs. You can find proposed -additions to stable in the +additions to stable in the proposed-updates directory. Those packages in proposed-updates that pass muster are periodically moved as a batch into the stable distribution and the revision level of the stable distribution is incremented (e.g., ‘3.0’ becomes ‘3.0r1’, ‘2.2r4’ becomes ‘2.2r5’, and so forth). Please refer to -uploads to the stable +uploads to the stable distribution for details. -Note that development under unstable continues during the -freeze period, since the unstable distribution remains in -place in parallel with testing. +Note that development under unstable continues during the +freeze period, since the unstable distribution remains in +place in parallel with testing.
@@ -699,20 +699,20 @@ the testing distribution.
Experimental -The experimental distribution is a special distribution. +The experimental distribution is a special distribution. It is not a full distribution in the same sense as `stable' and `unstable' are. Instead, it is meant to be a temporary staging area for highly experimental software where there's a good chance that the software could break your system, -or software that's just too unstable even for the unstable +or software that's just too unstable even for the unstable distribution (but there is a reason to package it nevertheless). Users who -download and install packages from experimental are +download and install packages from experimental are expected to have been duly warned. In short, all bets are off for the -experimental distribution. +experimental distribution. These are the sources.list 5 lines for -experimental: +experimental: deb http://ftp.xy.debian.org/debian/ experimental main @@ -720,36 +720,36 @@ deb-src http://ftp.xy.debian.org/debian/ experimental If there is a chance that the software could do grave damage to a system, it is -likely to be better to put it into experimental. For +likely to be better to put it into experimental. For instance, an experimental compressed file system should probably go into -experimental. +experimental. Whenever there is a new upstream version of a package that introduces new features but breaks a lot of old ones, it should either not be uploaded, or be -uploaded to experimental. A new, beta, version of some +uploaded to experimental. A new, beta, version of some software which uses a completely different configuration can go into -experimental, at the maintainer's discretion. If you are +experimental, at the maintainer's discretion. If you are working on an incompatible or complex upgrade situation, you can also use -experimental as a staging area, so that testers can get +experimental as a staging area, so that testers can get early access. -Some experimental software can still go into unstable, +Some experimental software can still go into unstable, with a few warnings in the description, but that isn't recommended because -packages from unstable are expected to propagate to -testing and thus to stable. You -should not be afraid to use experimental since it does not +packages from unstable are expected to propagate to +testing and thus to stable. You +should not be afraid to use experimental since it does not cause any pain to the ftpmasters, the experimental packages are automatically -removed once you upload the package in unstable with a +removed once you upload the package in unstable with a higher version number. New software which isn't likely to damage your system can go directly into -unstable. +unstable. -An alternative to experimental is to use your personal web +An alternative to experimental is to use your personal web space on people.debian.org. @@ -764,7 +764,7 @@ please consider using the option -v to
Release code names -Every released Debian distribution has a code name: Debian +Every released Debian distribution has a code name: Debian 1.1 is called `buzz'; Debian 1.2, `rex'; Debian 1.3, `bo'; Debian 2.0, `hamm'; Debian 2.1, `slink'; Debian 2.2, `potato'; Debian 3.0, `woody'; Debian 3.1, sarge; Debian 4.0, etch. There is also a ``pseudo-distribution'', called @@ -786,8 +786,8 @@ distribution (which is quite large). On the other hand, if we called the distribution directories -Debian-x.y from the beginning, people would think that -Debian release x.y is available. (This happened in the +Debian-x.y from the beginning, people would think that +Debian release x.y is available. (This happened in the past, where a CD-ROM vendor built a Debian 1.0 CD-ROM based on a pre-1.0 development version. That's the reason why the first official Debian release was 1.1, and not 1.0.) @@ -798,9 +798,9 @@ by their code names and not their release status (e.g., `slink'). These names stay the same during the development period and after the release; symbolic links, which can be changed easily, indicate the currently released stable distribution. That's why the real distribution directories use the -code names, while symbolic links for -stable, testing, and -unstable point to the appropriate release directories. +code names, while symbolic links for +stable, testing, and +unstable point to the appropriate release directories.
@@ -980,8 +980,8 @@ libdbd-mysql-perl | 1.2216-2.0.1 | testing | alpha libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc -In this example, you can see that the version in unstable -differs from the version in testing and that there has +In this example, you can see that the version in unstable +differs from the version in testing and that there has been a binary-only NMU of the package for the alpha architecture. Each version of the package has been recompiled on most of the architectures. @@ -1065,7 +1065,7 @@ aliases. Regular summary emails about the package's status. Currently, only progression -in testing is sent. +in testing is sent. @@ -1326,7 +1326,7 @@ evolution. Once you set up the VCS repository to generate commit notifications, you just have to make sure it sends a copy of those mails to sourcepackage_cvs@&pts-host;. -Only the people who accept the cvs keyword will receive +Only the people who accept the cvs keyword will receive these notifications. Note that the mail need to be sent from a debian.org machine, otherwise you'll have to add the X-PTS-Approved: 1 header. diff --git a/tools.dbk b/tools.dbk index 01ee79c..914d2f3 100644 --- a/tools.dbk +++ b/tools.dbk @@ -262,8 +262,8 @@ upstream changes into the repository. These utilities provide an infrastructure to facilitate the use of CVS by Debian maintainers. This allows one to keep separate CVS branches of a package -for stable, unstable and possibly -experimental distributions, along with the other benefits +for stable, unstable and possibly +experimental distributions, along with the other benefits of a version control system.
-- 2.30.2