Pisilinux3/pisi
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

* fix: both build and release numbers start from 1. also minor improvements, corrections in the text

Browse Source
This commit is contained in:
Eray Özkural
2005-11-16 11:31:55 +00:00
parent 4728c9e19c
commit 993b734bf6
1 changed files with 24 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/package_versions.tex
+23 -18
View File
@@ -5,7 +5,6 @@
\author{Eray \"Ozkural and T. Bar\i{}\c s Metin} \author{Eray \"Ozkural and T. Bar\i{}\c s Metin}
\begin{document} \begin{document}
\maketitle \maketitle
@@ -62,9 +61,9 @@ versioning scheme.
\subsection{Source Version} \subsection{Source Version}
Source version is the version number provided is provided by the Source version is the version number provided by the
upstream maintainer of the source archive used in package. It must be upstream maintainer of the source archive used in package. It must
always the same as the upstream version used. always be the same as the upstream version used.
\textbf{Example}: If the upstream archive name is \textbf{Example}: If the upstream archive name is
\emph{bash-3.0.tar.gz} the version number of the package is \emph{3.0} \emph{bash-3.0.tar.gz} the version number of the package is \emph{3.0}
@@ -92,25 +91,25 @@ The basic order of the priorities for suffixes is:\newline
\emph{p $>$ (no suffix) $>$ rc $>$ pre $>$ beta $>$ alpha}. \emph{p $>$ (no suffix) $>$ rc $>$ pre $>$ beta $>$ alpha}.
The scope of a source version string is global in the literal The scope of a source version string is global in the literal
sense. sense. It shall not vary from repository to repository.
The support for these special suffixes as well as usual alphanumeric The support for these special suffixes as well as usual alphanumeric
version string ordering has been implemented in P\.IS\.I. version string ordering has been implemented in P\.IS\.I.
\section{Identifying Package Sources} \section{Identifying Package Sources}
A PISI source has three identity elements written under A P\.IS\.I source has three identity elements written under
\texttt{SOURCE} tag: name, source version, and source release number. \texttt{SOURCE} tag: name, source version, and source release number.
We usually say just version and release number/release instead of We usually say just version and release number/release instead of
source version and source release number, respectively. Name is available in source version and source release number, respectively. Name is available in
the \texttt{<Name>} tag. Version and release are available in the last the \texttt{<Name>} tag. Version and release are available in the last
\texttt{<Update>} element of \texttt{<History>} tag. \texttt{<Update>} element of \texttt{<History>} tag of a \texttt{PSPEC}.
The name of a source package is constant throughout its revision The name of a source package is constant throughout its revision
history. The version is the original version, given by its history. The version is the original version, given by its
programmers. Release is a nonnegative integer. Name and release is sufficient to uniquely identify a programmers. Release is a positive integer. Name and release
particular PISI source revision. That is, version and release are is sufficient to uniquely identify a particular PISI source revision.
independent. That is, version and release are independent.
\subsection{Release Number} \subsection{Release Number}
@@ -121,19 +120,19 @@ the actions.py, pspec.xml or any file in the source package
directory. This change is indicated in \texttt{<Update>} tags manually directory. This change is indicated in \texttt{<Update>} tags manually
by the package maintainer. by the package maintainer.
The initial release of a package is by default \texttt{0}. The release The initial release of a package is by default \texttt{1}. The release
number always increments by $1$ in each revision in the number always increments by $1$ in each revision in the
\texttt{History}, even the slightest ones, but it never decrements. \texttt{History}, even the slightest ones, but it never decrements.
The scope of the release number is a given distribution, regardless of The scope of the release number is a given distribution, regardless of
its version, e.g. Pardus. its version, e.g. Pardus.
In the near future, PISI will have strict checks for release numbers. In the future, PISI will have strict checks for release numbers.
\subsection{Dependency Specifications} \subsection{Dependency Specifications}
We allow a package to use both source version and release to identify We allow a package to use both source version and release to identify
a particular or a range of package versions. a particular version or a range of package versions.
\section{Identifying Binary packages} \section{Identifying Binary packages}
@@ -153,16 +152,21 @@ architecture regardless of the source version.
Similarly to source release number, binary build number is the number Similarly to source release number, binary build number is the number
of changes that are made to a binary package. By change, we mean any of changes that are made to a binary package. By change, we mean any
bit change. The existence of a change is tested by comparing the bit change. The existence of a change is tested by comparing the
cryptographic checksums in files.xml with the previous build, and the cryptographic checksums in files.xml with those of the previous build, and the
build number is automatically determined by the P\.IS\.I build system. build number is automatically determined by the P\.IS\.I build system.
The build number starts from $1$ as in release number, and increments
by one with each binary change.
The user never interferes with the build number himself. However, if The user never interferes with the build number himself. However, if
the user fails to provide the previous build, then a package without the user fails to provide the previous build, then a package without
a build number is built. a build number is built. A package without a build number is evaluated
on the basis of release number, which is guaranteed to exist.
The scope of a build number is a given distribution build environment The scope of a build number is a given distribution build environment
for a particular architecture. Therefore, it is not used in dependency for a particular architecture, which may vary from repository to
specifications. repository. Therefore, it is not used in dependency
specifications. However, the system does assume that a build of a
given package and architecture is unique in a given repository.
\section{Package File Names} \section{Package File Names}
@@ -176,6 +180,7 @@ to its identification, separated by dashes:
In the future, it may be necessary to extend the notion of release In the future, it may be necessary to extend the notion of release
number and build number to support branches and forks of a number and build number to support branches and forks of a
distribution. A proposal was to have CVS-like branching. distribution. A proposal was to have CVS-like branching, but it
was dismissed as unnecessary.
\end{document} \end{document}