我的书签
添加书签
移除书签4.17. Vendor-specific patch series
Packages in the Debian archive using the 3.0 (quilt) source package format should not contain a non-default series file. That is, there should not exist a file debian/patches/foo.series for any foo.
Rationale:
This allows maintaining the list separately from the policy documents (the list does not need the kind of control that the policy documents do).
Having a separate package allows one to install the build-essential packages on a machine, as well as allowing other packages such as tasks to require installation of the build-essential packages using the depends relation.
The separate package allows bug reports against the list to be categorized separately from the policy management process in the BTS.
The reason for this is that dependencies change, and you should list all those packages, and only those packages that you need directly. What others need is their business. For example, if you only link against libimlib, you will need to build-depend on libimlib2-dev but not against any libjpeg* packages, even though libimlib2-dev currently depends on them: installation of libimlib2-dev will automatically ensure that all of its run-time dependencies are satisfied.
Mistakes in changelogs are usually best rectified by making a new changelog entry rather than “rewriting history” by editing old changelog entries.
Although there is nothing stopping an author who is also the Debian maintainer from using this changelog for all their changes, it will have to be renamed if the Debian and upstream maintainers become different people. In such a case, however, it might be better to maintain the package as a non-native package.
To be precise, the string should match the following Perl regular expression:
/closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
Then all of the bug numbers listed will be closed by the archive maintenance software (dak) using the version of the changelog entry.
In the case of a sponsored upload, the uploader signs the files, but the changelog maintainer name and address are those of the person who prepared this release. If the preparer of the release is not one of the usual maintainers of the package (as listed in the Maintainer or Uploaders control fields of the package), the first line of the changelog is conventionally used to explain why a non-maintainer is uploading the package. The Debian Developer’s Reference (see Related documents) documents the conventions used.
This is the same as the format generated by date -R.
The rationale is that there is some information conveyed by knowing the age of the file, for example, you could recognize that some documentation is very old by looking at the modification time, so it would be nice if the modification time of the upstream source would be preserved.
This is not currently detected when building source packages, but only when extracting them.
Hard links may be permitted at some point in the future, but would require a fair amount of work.
Setgid directories are allowed.
Another common way to do this is for build to depend on build-stamp and to do nothing else, and for the build-stamp target to do the building and to touch build-stamp on completion. This is especially useful if the build routine creates a file or directory called build; in such a case, build will need to be listed as a phony target (i.e., as a dependency of the .PHONY target). See the documentation of make for more information on phony targets.
This split allows binary-only builds to not install the dependencies required for the build-indep target and skip any resource-intensive build tasks that are only required when building architecture-independent binary packages.
The fakeroot package often allows one to build a package correctly even without being root.
Some packages support any delimiter, but whitespace is the easiest to parse inside a makefile and avoids ambiguity with flag values that contain commas.
Packages built with make can often implement this by passing the -jn option to make.
files.new is used as a temporary file by dpkg-gencontrol and dpkg-distaddfile - they write a new version of files here before renaming it, to avoid leaving a corrupted copy if an error occurs.
For example, parts of the GNU build system work like this.
Having multiple copies of the same code in Debian is inefficient, often creates either static linking or shared library conflicts, and, most importantly, increases the difficulty of handling security vulnerabilities in the duplicated code.
This is Debian’s precisification of the reproducible-builds.org definition.
