Niko Tyni [Fri, 30 May 2014 11:10:22 +0000 (14:10 +0300)]
All packages using Perl vendorarch directory need a perlapi-* dependency
Having $Config{vendorarch} change between Perl major versions (for
multiarch or other reasons) implies that packages using it need a strict
dependency on those versions of perl-base that have a compatible search
path (@INC).
The vast majority of these packages are binary ("XS") modules, where we
already require a dependency on the virtual package perlapi-*, provided
by perl-base. The name of this virtual package will change when the
interface between the Perl interpreter and the modules changes.
If we consider @INC part of that interface, we can use the existing
mechanism also for the few nonbinary modules using $Config{vendorarch}.
This is a new requirement that currently affects six packages in
the archive.
Niko Tyni [Thu, 15 May 2014 20:35:52 +0000 (23:35 +0300)]
Recommend $Config{vendorarch} et al. over hardcoding @INC locations
The most pressing need for this is for including the multiarch
triplet in vendorarch, but it is also a logical continuation for the
$Config{debian_abi} concept introduced earlier.
If we ever have to make a binary incompatible change without a major
version bump, we'll probably have to change @INC too, at least for
locally installed binary modules (sitearch).
Niko Tyni [Fri, 16 May 2014 16:40:35 +0000 (19:40 +0300)]
Perl Policy: Explain %Config earlier
Move the footnote about the Config module to the first reference
The new Config reference was introduced in cc34dcc0 but the
footnote wasn't moved accordingly.
Niko Tyni [Thu, 15 May 2014 20:35:11 +0000 (23:35 +0300)]
Document that @INC has /usr/lib/perl/5.18, not /usr/lib/perl/5.18.2
Since at least 5.8.4-8 (Debian sarge release), the Perl search
path for the core modules has used the major version (5.18)
instead of the full one (5.18.2).
Guillem Jover [Thu, 14 Feb 2013 18:09:11 +0000 (19:09 +0100)]
Switch appendix section for dpkg-buildpackage into a stub
The section only documents things already present in the man page,
and in cases the documentation is outdated. Just turn it into a stub
pointing to the man page, to avoid renumbering issues.
Charles Plessy [Thu, 1 Mar 2012 13:58:41 +0000 (22:58 +0900)]
Rely on triggers instead of calling update-mime
Closes: 661816
This patch also:
- Removes mention of the MIME policy. This is a leftover from its removal.
- Documents /usr/lib/mime/packages/, and recommends to use binary package
names as a file names.
- Cosmetically changes the emphasis on a "should not".
Move alternative init systems to avoid renumbering
While keeping all the init-related material together would be nice,
it causes section renumbering, which causes other problems. Move it
to the bottom of that chapter. We'll fix this when we rewrite all of
Policy and reorder everything.
Steve Langasek [Mon, 10 Jan 2011 01:58:58 +0000 (19:58 -0600)]
Document generic and upstart-specific init-system requirements
Add a new section on alternative init systems that outlines the
compatibility requirements for both init replacements and packages shipping
upstart jobs. Closes: #591791
Jonathan Nieder [Sun, 12 Aug 2012 23:30:54 +0000 (16:30 -0700)]
symbols/shlibs policy: cosmetic fixes
Use "zlib1g (>= 1:1.2.3.3.dfsg-2~)" in the sample shlibs dependency
field to emphasize the backport-friendly convention described in the
sharedlibs-updates section.
Also correct two small typos --- one sentence is uncapitalized and
another missing a noun --- and rephrase a sentence that describes when
to bump the dependency-version to make it easier to read.
Jonathan Nieder [Sun, 12 Aug 2012 20:43:50 +0000 (13:43 -0700)]
Clarifications to symbols and shlibs policy
subject/verb agreement: s/provide/provides/
Packages with libraries or binaries linking to a shared library must
use symbols or shlibs files to compute their dependencies. Packages
that dlopen() a shared library should do so as well, but since that
is not typical practice and the tools to do that don't exist, it is
not made a policy "must" yet.
The minimal version for a symbol can be bumped after the version of
the package in which the symbol was introduced.
Add a footnote explaining why shlibs files cannot be used for
libraries with unusual sonames.
The shlibs file for a library udeb goes in the corresponding deb.
The library deb corresponding to a udeb is supposed to provide a
shlibs file, rather than consuming (using) one.
Add "for example" when talking about dpkg-shlibdeps -T. This is
just an illustration and not meant to be normative.
If a library is used both directly and indirectly, the direct
dependency still needs to be declared.
Backward-compatibility is defined in terms of what reasonable
programs and libraries need.
In the normal case, symbols files go in dpkg's admindir as package
control files.
wording fix: "dependency on" avoids some of the ambiguity in
"dependency of".
Russ Allbery [Sun, 12 Aug 2012 20:14:55 +0000 (13:14 -0700)]
Make build-arch and build-indep required targets
Implement the Debian Technical Committee decision in #629385.
Remove the normative documentation of what to do when the targets
aren't provided. Remove the informative footnote saying that
the build daemons don't support this.
Charles Plessy [Sat, 7 Jan 2012 06:00:30 +0000 (15:00 +0900)]
Document VCS fields
Uses Developers's Reference §6.2.5 for inspiration.
Closes: #654958
[jrnieder@gmail.com:
- declared repositories should be publicly accessible
- Vcs-Browser should point to a webapp
- Vcs-<system> should use the version control system's conventional syntax
- if multiple branches are used for packaging (e.g., "stable",
"testing", "sid"), any one of them will do
- for Vcs-Git, "-b <branch>" can be omitted when the intended branch is the
default branch
- list some Vcs-<foo> fields by name in the lists in §5.2 and §5.4
- declared repositories track development of the Debian source
package, not just the upstream code
- Vcs-Browser can be a web interface using any protocol (e.g., HTTPS
is fine)
- picking a good branch is optional
Thanks to Russ Allbery for several improvements to the text.]
Russ Allbery [Sat, 17 Mar 2012 18:04:14 +0000 (11:04 -0700)]
Further symbols wording fixes from Charles Plessy
Retain the dpkg-shlibdeps section in the appendix as a stub pointing
to the main page so that we don't renumber subsequent sections. Add
more explanation for why dependencies change for each build of a
binary package. Combine the dpkg-shlibdeps instructions somewhat and
mention that debian/substvars is only a default.
Russ Allbery [Sat, 17 Mar 2012 17:41:41 +0000 (10:41 -0700)]
Substantial revision to the new symbols draft
Pull out lots of information that's shared between symbols and shlibs
into new sections directly under shared library dependencies. Make
both symbols and shlibs subsections of that section. Flesh out the
documentation of how to choose between symbols and shlibs and what the
differences in the systems are.
Document that C++ libraries may be better off with shlibs and don't
deprecate shlibs quite as much.
Move the information on how to determine the shared library soversion
to the runtime shared library section where it's now primarily used,
and reference it in the shlibs section.
projects / debian / debian-policy.git / log