X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=developers-reference.git;a=blobdiff_plain;f=beyond-pkging.dbk;h=371fba21d3b1e20e312448a2b0245795af0cb062;hp=2eaac0a4da78de60ccc0d2017a2e3f7c5f398c8a;hb=3d937a844b4beb5500d6bc38eb1e806f54ebbc69;hpb=373b7237c8f6b807ce10c0a8e123ca05f890969d diff --git a/beyond-pkging.dbk b/beyond-pkging.dbk index 2eaac0a..371fba2 100644 --- a/beyond-pkging.dbk +++ b/beyond-pkging.dbk @@ -40,7 +40,7 @@ generally ease the process. Make sure the bug is not already filed against a package. Each package has a bug list easily reachable at -http://&bugs-host;/packagename +http://&bugs-host;/packagename. Utilities like querybts 1 can also provide you with this information (and reportbug will usually invoke @@ -337,27 +337,27 @@ Debian Developers can sponsor packages. Debian Maintainers can't. The process of sponsoring a package is: -The maintainer prepares a source package (.dsc) and puts it online -somewhere (like on mentors.debian.net). Or even better, she provides -a link to a public VCS repository where +The maintainer prepares a source package (.dsc) and puts it online +somewhere (like on mentors.debian.net) or even better, provides +a link to a public VCS repository (see ) where the package is maintained. The sponsor downloads (or checkouts) the source package. -The sponsor reviews the source package. If she finds issues, she -informs the maintainer and asks her to provide a fixed version (the +The sponsor reviews the source package. If they find issues, they +inform the maintainer and ask them to provide a fixed version (the process starts over at step 1). -The sponsor could not find any remaining problem. She builds the -package, signs it, and uploads it to Debian. +The sponsor could not find any remaining problem. They build the +package, sign it, and upload it to Debian. -But before delving in the details of how to sponsor a package, you should +Before delving in the details of how to sponsor a package, you should ask yourself whether adding the proposed package is beneficial to Debian. @@ -365,19 +365,19 @@ There's no simple rule to answer this question, it can depend on many factors: is the upstream codebase mature and not full of security holes? Are there pre-existing packages that can do the same task and how do they compare to this new package? Has the new package been requested by users -and how large is the userbase? How active are the upstream developers? +and how large is the user base? How active are the upstream developers? You should also ensure that the prospective maintainer is going -to be a good maintainer. Does she already have some experience with other -packages? If yes, is she doing a good job with them (check out some bugs)? -Is she familiar with the package and its programming language? -Does she have the skills needed for this package? If not, is she able +to be a good maintainer. Do they already have some experience with other +packages? If yes, are they doing a good job with them (check out some bugs)? +Are they familiar with the package and its programming language? +Do they have the skills needed for this package? If not, are they able to learn them? -It's also a good idea to know where she stands towards Debian: does -she agree with Debian's philosophy and does she intend to join Debian? +It's also a good idea to know where they stand with respect to Debian: do +they agree with Debian's philosophy and do they intend to join Debian? Given how easy it is to become a Debian Maintainer, you might want to only sponsor people who plan to join. That way you know from the start that you won't have to act as a sponsor indefinitely. @@ -406,8 +406,8 @@ it's also not enough. The rest of this section contains a non-exhaustive list of points to check in your review. -You can find more checks in the wiki: several developers share their own -sponsorship checklists at . +You can find more checks in the wiki where several developers share their own +sponsorship checklists. @@ -418,19 +418,19 @@ distributed by the upstream author (when the sources are repackaged for Debian, generate the modified tarball yourself). -Run lintian (see ). It will catch many common -problems. Be sure to verify that any lintian overrides setup by the +Run lintian (see ). It will catch many common +problems. Be sure to verify that any lintian overrides setup by the maintainer is fully justified. -Run licensecheck (part of ) and verify that +Run licensecheck (part of ) and verify that debian/copyright seems correct and complete. Look for license problems (like files with “All rights reserved” headers, or with a non-DFSG compliant license). grep -ri is your friend for this task. -Build the package with pbuilder (or any similar tool, see Build the package with pbuilder (or any similar tool, see ) to ensure that the build-dependencies are complete. @@ -445,14 +445,16 @@ best practices (see )? Do you see some possible improvements? -Proofread the maintainer scripts (preinst, postinst, prerm, postrm, -config): will the preinst/postrm work when the dependencies are not +Proofread the maintainer scripts (preinst, +postinst, prerm, +postrm, config): will the +preinst/postrm work when the dependencies are not installed? Are all the scripts idempotent (i.e. can you run them multiple times without consequences)? -Review any change to upstream files (either in .diff.gz, or in -debian/patches/ or directly embedded in the debian +Review any change to upstream files (either in .diff.gz, or in +debian/patches/ or directly embedded in the debian tarball for binary files). Are they justified? Are they properly documented (with DEP-3 for patches)? @@ -464,30 +466,30 @@ linkend="best-pkging-practices"/>)? Build the packages, install them and try the software. Ensure you can -remove and purge the packages. Maybe test them with piuparts. +remove and purge the packages. Maybe test them with piuparts. If the audit did not reveal any problem, you can build the package and -upload it to Debian. But remember that even if you're not the maintainer, -the sponsor is still responsible of what he uploaded to Debian. That's +upload it to Debian. Remember that even if you're not the maintainer, +as a sponsor you are still responsible for what you upload to Debian. That's why you're encouraged to keep up with the package through the . -Note that you should not need to modifiy the source package to put your name -in the changelog or in the control file. The Maintainer +Note that you should not need to modify the source package to put your name +in the changelog or in the control file. The Maintainer field of the control file and the changelog should list the person who did the -packaging, i.e. the sponsoree. That way she will get all the BTS mail. +packaging, i.e. the sponsoree. That way they will get all the BTS mail. -Instead you should instruct dpkg-buildpackage to use your key for -the signature. You do that with the -k option: +Instead you should instruct dpkg-buildpackage to use your key for +the signature. You do that with the -k option: dpkg-buildpackage -kKEY-ID -If you use debuild and debsign, you can even configure it permanently +If you use debuild and debsign, you can even configure it permanently in ~/.devscripts: DEBSIGN_KEYID=KEY-ID @@ -514,13 +516,13 @@ and rebuild it (or download the current binary packages with Read the new changelog entry, it should tell you what to expect during the review. The main tool you will use is debdiff (provide by -the devscripts package), you can run it with two source packages (.dsc -files), or two binary packages, or two .changes files (it will then -compare all the binary packages listed in the .changes). +the devscripts package), you can run it with two source packages (.dsc +files), or two binary packages, or two .changes files (it will then +compare all the binary packages listed in the .changes). If you compare the source packages (excluding upstream files in the case -of a new upstream version, for example by filtering the output of debdiff +of a new upstream version, for example by filtering the output of debdiff with filterdiff -i '*/debian/*'), you must understand all the changes you see and they should be properly documented in the Debian changelog. @@ -537,11 +539,11 @@ linkend="pkg-tracking-system"/>) to verify if the maintainer has not missed something important. Maybe there are translations updates sitting in the BTS that could have been integrated. Maybe the package has been NMUed and the maintainer forgot to integrate the changes from the -NMU in his package. Maybe there's a release critical bug that he has left -unhandled and that's blocking migration to testing. Whatever. If you find -something that she could have done (better), it's time to tell her so that -she can improve for next time. And so that she has a better understanding -of her responsibilities. +NMU into their package. Maybe there's a release critical bug that they have +left unhandled and that's blocking migration to testing. +If you find something that they could have done (better), it's time to tell +them so that they can improve for next time, and so that they have a better +understanding of their responsibilities. If you have found no major problem, upload the new version. Otherwise