Daily updated video selection with the latest travel and holiday movies. Dream of your next trip to Thailand while looking at the biggest collection of videos from the land of smiles.


Most popular search tags:
Bangkok | Thailand resorts | Pattaya | Phuket | Chiang Mai

dbdvrf #15 Debian Developer's Reference

Back


http://packages.debian.org/sid/developers-reference - - on the list, and lets them know if anyone else is working on it already. * It lets other people thinking about working on the package know that there already is a volunteer, so efforts may be shared. * It lets the rest of the maintainers know more about the package than the one line description and the usual changelog entry ``Initial release'' that gets posted to [ debian-devel-changes@ lists.debian.org]. * It is helpful to the people who live off unstable (and form our first line of testers). We should encourage these people. * The announcements give maintainers and other interested parties a better feel of what is going on, and what is new, in the project. Please see http://ftp-master.debian.org/REJECT-FAQ.html for common rejection reasons for a new package. 5.2. Recording changes in the package Changes that you make to the package need to be recorded in the debian/changelog. These changes should provide a concise description of what was changed, why (if it's in doubt), and note if any bugs were closed. They also record when the package was completed. This file will be installed in /usr/share/doc/ package/changelog.Debian.gz, or /usr/share/doc/package/ changelog.gz 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 Section 5.5, Picking a distribution . More information about the structure of thisfile can be found in the Debian Policy section titled debian/ changelog. Changelog entries can be used to automatically close Debian bugs when the package is installed into the archive. See Section 5.8.4, When bugs are closed by new uploads . It is conventional that the changelog entry of a package that contains a new upstream version of the software looks like this: * new upstream version There are tools to help you create entries and finalize the changelog for release — see Section A.6.1, devscripts and Section A.6.6, dpkg-dev-el . See also Section 6.3, Best practices for debian/changelog . 5.3. Testing the package Before you upload your package, you should do basic testing on it. At a minimum, you should try the following activities (you'll need to have an older version of the same Debian package around): * Install the package and make sure the software works, or upgrade the package from an older version to your new version if a Debian package for it already exists. * Run lintian over the package. You can run lintian as follows: lintian -v package-version.changes. This will check the source package as well as the binary package. If you don't understand the output that lintian generates, try adding the -i switch, which will cause lintian to output a very verbose description of the problem. Normally, a package should not be uploaded if it causes lintian to emit errors (they will start with E). For more information on lintian, see Section A.2.1, lintian . * Optionally run Section A.2.2, debdiff to analyze changes from an older version, if one exists. * Downgrade the package to the previous version (if one exists) — this tests the postrm and prerm scripts. * Remove the package, then reinstall it. * Copy the source package in a different directory and try unpacking it and rebuilding it. This tests if the package relies on existing files outside of it, or if it relies on permissions being preserved on the files shipped inside the .diff.gz file. 5.4. Layout of the source package There are two types of Debian source packages: * the so-called native packages, where there is no distinction between the original sources and the patches applied for Debian * the (more common) packages where there's an original source tarball file accompanied by another file that contains the patches applied for Debian For the native packages, the source package includes a Debian source control file (.dsc) and the source tarball (.tar.gz). A source package of a non-native package includes a Debian source control file, the original source tarball (.orig.tar.gz) and the Debian patches (.diff.gz). Whether a package is native or not is determined when it is built by dpkg-buildpackage(1). The rest of this section relates only to non-native packages. The first time a version is uploaded which corresponds to a particular upstream version, the original source tar file should be uploaded and included in the .changes file. Subsequently, this very same tar file should be used to build the new diffsand .dsc files, and will not need to be re-uploaded. By default, dpkg-genchanges and dpkg-buildpackage will include the original source tar file if and only if the Debian revision

Category: Education
Uploaded: December 2nd, 2008 @ 8:50 am
Author: h4ck3rm1k3

Length: 07:20
Rating:
Views: 13

Tags: debian developers reference

Related Video Links:


» View Video Comments For dbdvrf #15 Debian Developer's Reference
» View h4ck3rm1k3's Other Uploaded Videos

Video Thumbnails:


Thumbnail #1 Video Thumbnail #1:
Thumbnail #2 Video Thumbnail #2:
Thumbnail #3 Video Thumbnail #3:


Video Embedding Code:


Video Url:


Embed Code:

* Embed this video on your website, social bookmark, myspace, or blog.