Skip to content

I
inary
Kaydet (Commit) cb682c00 authored tarafından Suleyman Poyraz's avatar Suleyman Poyraz
Dosyalara gözat
Seçenekler

tüm dokümantasyon yeniden yazılmak üzere terkedildi

üst c5f96d5d
Expand all Show whitespace changes
Inline Side-by-side
Showing with 0 additions and 1159 deletions
doc/algorithm.sty deleted 100644 → 0
Dosyayı görüntüle @ c5f96d5d
% ALGORITHM STYLE -- Released 8 April 1996
% for LaTeX-2e
% Copyright -- 1994 Peter Williams
% E-mail Peter.Williams@dsto.defence.gov.au
\NeedsTeXFormat{LaTeX2e}
\ProvidesPackage{algorithm}
\typeout{Document Style `algorithm' - floating environment}
\RequirePackage{float}
\RequirePackage{ifthen}
\newcommand{\ALG@within}{nothing}
\newboolean{ALG@within}
\setboolean{ALG@within}{false}
\newcommand{\ALG@floatstyle}{ruled}
\newcommand{\ALG@name}{Algorithm}
\newcommand{\listalgorithmname}{List of \ALG@name s}
% Declare Options
% first appearance
\DeclareOption{plain}{
\renewcommand{\ALG@floatstyle}{plain}
}
\DeclareOption{ruled}{
\renewcommand{\ALG@floatstyle}{ruled}
}
\DeclareOption{boxed}{
\renewcommand{\ALG@floatstyle}{boxed}
}
% then numbering convention
\DeclareOption{part}{
\renewcommand{\ALG@within}{part}
\setboolean{ALG@within}{true}
}
\DeclareOption{chapter}{
\renewcommand{\ALG@within}{chapter}
\setboolean{ALG@within}{true}
}
\DeclareOption{section}{
\renewcommand{\ALG@within}{section}
\setboolean{ALG@within}{true}
}
\DeclareOption{subsection}{
\renewcommand{\ALG@within}{subsection}
\setboolean{ALG@within}{true}
}
\DeclareOption{subsubsection}{
\renewcommand{\ALG@within}{subsubsection}
\setboolean{ALG@within}{true}
}
\DeclareOption{nothing}{
\renewcommand{\ALG@within}{nothing}
\setboolean{ALG@within}{true}
}
\DeclareOption*{\edef\ALG@name{\CurrentOption}}
% ALGORITHM
%
\ProcessOptions
\floatstyle{\ALG@floatstyle}
\ifthenelse{\boolean{ALG@within}}{
\ifthenelse{\equal{\ALG@within}{part}}
{\newfloat{algorithm}{htbp}{loa}[part]}{}
\ifthenelse{\equal{\ALG@within}{chapter}}
{\newfloat{algorithm}{htbp}{loa}[chapter]}{}
\ifthenelse{\equal{\ALG@within}{section}}
{\newfloat{algorithm}{htbp}{loa}[section]}{}
\ifthenelse{\equal{\ALG@within}{subsection}}
{\newfloat{algorithm}{htbp}{loa}[subsection]}{}
\ifthenelse{\equal{\ALG@within}{subsubsection}}
{\newfloat{algorithm}{htbp}{loa}[subsubsection]}{}
\ifthenelse{\equal{\ALG@within}{nothing}}
{\newfloat{algorithm}{htbp}{loa}}{}
}{
\newfloat{algorithm}{htbp}{loa}
}
\floatname{algorithm}{\ALG@name}
\newcommand{\listofalgorithms}{\listof{algorithm}{\listalgorithmname}}
doc/algorithmic.sty deleted 100644 → 0
Dosyayı görüntüle @ c5f96d5d
% ALGORITHMIC STYLE -- Released 8 APRIL 1996
% for LaTeX version 2e
% Copyright -- 1994 Peter Williams
% E-mail PeterWilliams@dsto.defence.gov.au
\NeedsTeXFormat{LaTeX2e}
\ProvidesPackage{algorithmic}
\typeout{Document Style `algorithmic' - environment}
%
\RequirePackage{ifthen}
\RequirePackage{calc}
\newboolean{ALC@noend}
\setboolean{ALC@noend}{false}
\newcounter{ALC@line}
\newcounter{ALC@rem}
\newlength{\ALC@tlm}
%
\DeclareOption{noend}{\setboolean{ALC@noend}{true}}
%
\ProcessOptions
%
% ALGORITHMIC
\newcommand{\algorithmicrequire}{\textbf{Require:}}
\newcommand{\algorithmicensure}{\textbf{Ensure:}}
\newcommand{\algorithmiccomment}[1]{\{#1\}}
\newcommand{\algorithmicend}{\textbf{end}}
\newcommand{\algorithmicif}{\textbf{if}}
\newcommand{\algorithmicthen}{\textbf{then}}
\newcommand{\algorithmicelse}{\textbf{else}}
\newcommand{\algorithmicelsif}{\algorithmicelse\ \algorithmicif}
\newcommand{\algorithmicendif}{\algorithmicend\ \algorithmicif}
\newcommand{\algorithmicfor}{\textbf{for}}
\newcommand{\algorithmicforall}{\textbf{for all}}
\newcommand{\algorithmicdo}{\textbf{do}}
\newcommand{\algorithmicendfor}{\algorithmicend\ \algorithmicfor}
\newcommand{\algorithmicwhile}{\textbf{while}}
\newcommand{\algorithmicendwhile}{\algorithmicend\ \algorithmicwhile}
\newcommand{\algorithmicloop}{\textbf{loop}}
\newcommand{\algorithmicendloop}{\algorithmicend\ \algorithmicloop}
\newcommand{\algorithmicrepeat}{\textbf{repeat}}
\newcommand{\algorithmicuntil}{\textbf{until}}
\def\ALC@item[#1]{%
\if@noparitem \@donoparitem
\else \if@inlabel \indent \par \fi
\ifhmode \unskip\unskip \par \fi
\if@newlist \if@nobreak \@nbitem \else
\addpenalty\@beginparpenalty
\addvspace\@topsep \addvspace{-\parskip}\fi
\else \addpenalty\@itempenalty \addvspace\itemsep
\fi
\global\@inlabeltrue
\fi
\everypar{\global\@minipagefalse\global\@newlistfalse
\if@inlabel\global\@inlabelfalse \hskip -\parindent \box\@labels
\penalty\z@ \fi
\everypar{}}\global\@nobreakfalse
\if@noitemarg \@noitemargfalse \if@nmbrlist \refstepcounter{\@listctr}\fi \fi
\sbox\@tempboxa{\makelabel{#1}}%
\global\setbox\@labels
\hbox{\unhbox\@labels \hskip \itemindent
\hskip -\labelwidth \hskip -\ALC@tlm
\ifdim \wd\@tempboxa >\labelwidth
\box\@tempboxa
\else \hbox to\labelwidth {\unhbox\@tempboxa}\fi
\hskip \ALC@tlm}\ignorespaces}
%
\newenvironment{algorithmic}[1][0]{
\let\@item\ALC@item
\newcommand{\ALC@lno}{%
\ifthenelse{\equal{\arabic{ALC@rem}}{0}}
{{\footnotesize \arabic{ALC@line}:}}{}%
}
\let\@listii\@listi
\let\@listiii\@listi
\let\@listiv\@listi
\let\@listv\@listi
\let\@listvi\@listi
\let\@listvii\@listi
\newenvironment{ALC@g}{
\begin{list}{\ALC@lno}{ \itemsep\z@ \itemindent\z@
\listparindent\z@ \rightmargin\z@
\topsep\z@ \partopsep\z@ \parskip\z@\parsep\z@
\leftmargin 1em
\addtolength{\ALC@tlm}{\leftmargin}
}
}
{\end{list}}
\newcommand{\ALC@it}{\addtocounter{ALC@line}{1}\addtocounter{ALC@rem}{1}\ifthenelse{\equal{\arabic{ALC@rem}}{#1}}{\setcounter{ALC@rem}{0}}{}\item}
\newcommand{\ALC@com}[1]{\ifthenelse{\equal{##1}{default}}%
{}{\ \algorithmiccomment{##1}}}
\newcommand{\REQUIRE}{\item[\algorithmicrequire]}
\newcommand{\ENSURE}{\item[\algorithmicensure]}
\newcommand{\STATE}{\ALC@it}
\newcommand{\COMMENT}[1]{\algorithmiccomment{##1}}
\newenvironment{ALC@if}{\begin{ALC@g}}{\end{ALC@g}}
\newenvironment{ALC@for}{\begin{ALC@g}}{\end{ALC@g}}
\newenvironment{ALC@whl}{\begin{ALC@g}}{\end{ALC@g}}
\newenvironment{ALC@loop}{\begin{ALC@g}}{\end{ALC@g}}
\newenvironment{ALC@rpt}{\begin{ALC@g}}{\end{ALC@g}}
\renewcommand{\\}{\@centercr}
\newcommand{\IF}[2][default]{\ALC@it\algorithmicif\ ##2\ \algorithmicthen%
\ALC@com{##1}\begin{ALC@if}}
\newcommand{\ELSE}[1][default]{\end{ALC@if}\ALC@it\algorithmicelse%
\ALC@com{##1}\begin{ALC@if}}
\newcommand{\ELSIF}[2][default]%
{\end{ALC@if}\ALC@it\algorithmicelsif\ ##2\ \algorithmicthen%
\ALC@com{##1}\begin{ALC@if}}
\newcommand{\FOR}[2][default]{\ALC@it\algorithmicfor\ ##2\ \algorithmicdo%
\ALC@com{##1}\begin{ALC@for}}
\newcommand{\FORALL}[2][default]{\ALC@it\algorithmicforall\ ##2\ %
\algorithmicdo%
\ALC@com{##1}\begin{ALC@for}}
\newcommand{\WHILE}[2][default]{\ALC@it\algorithmicwhile\ ##2\ %
\algorithmicdo%
\ALC@com{##1}\begin{ALC@whl}}
\newcommand{\LOOP}[1][default]{\ALC@it\algorithmicloop%
\ALC@com{##1}\begin{ALC@loop}}
\newcommand{\REPEAT}[1][default]{\ALC@it\algorithmicrepeat%
\ALC@com{##1}\begin{ALC@rpt}}
\newcommand{\UNTIL}[1]{\end{ALC@rpt}\ALC@it\algorithmicuntil\ ##1}
\ifthenelse{\boolean{ALC@noend}}{
\newcommand{\ENDIF}{\end{ALC@if}}
\newcommand{\ENDFOR}{\end{ALC@for}}
\newcommand{\ENDWHILE}{\end{ALC@whl}}
\newcommand{\ENDLOOP}{\end{ALC@loop}}
}{
\newcommand{\ENDIF}{\end{ALC@if}\ALC@it\algorithmicendif}
\newcommand{\ENDFOR}{\end{ALC@for}\ALC@it\algorithmicendfor}
\newcommand{\ENDWHILE}{\end{ALC@whl}\ALC@it\algorithmicendwhile}
\newcommand{\ENDLOOP}{\end{ALC@loop}\ALC@it\algorithmicendloop}
}
\renewcommand{\@toodeep}{}
\begin{list}{\ALC@lno}{\setcounter{ALC@line}{0}\setcounter{ALC@rem}{0}%
\itemsep\z@ \itemindent\z@ \listparindent\z@%
\partopsep\z@ \parskip\z@ \parsep\z@%
\labelsep 0.5em \topsep 0.2em%
\ifthenelse{\equal{#1}{0}}
{\labelwidth 0.5em }
{\labelwidth 1.2em }
\leftmargin\labelwidth \addtolength{\leftmargin}{\labelsep}
\ALC@tlm\labelsep
}
}
{\end{list}}
doc/dependency.tex deleted 100644 → 0
Dosyayı görüntüle @ c5f96d5d
This diff is collapsed.
doc/inary-db.xmi deleted 100644 → 0
Dosyayı görüntüle @ c5f96d5d
This diff is collapsed.
doc/package_versions.tex deleted 100644 → 0
Dosyayı görüntüle @ c5f96d5d
\documentclass[a4paper,11pt]{article}
\title{P\.IS\.I Packages: Version Policy v0.2}
\date{\today}
\author{Eray \"Ozkural and T. Bar\i{}\c s Metin}
\begin{document}
\maketitle
\section*{Revision History}
\begin{itemize}
\item v0.1: Bar\i\c s Metin wrote the first version preparing the outline,
detailed Source Version Section, and started the Section on Release Number.
\item v0.2: Eray \"Ozkural wrote a detailed introduction, added
explanations of release and build numbers, reorganized a bit.
\end{itemize}
\section{Introduction}
This document explains the \emph{version policy} that applies to
P\.IS\.I packages. Classically, the issue of distinguishing source and
binary distributions unambiguously has not received a rigorous
treatment in the context of LINUX distributions. We have identified
several shortcomings of the usual practices of extending the original
version with suffixes and prefixes, colorfully illustrated in the
following common problems.
\begin{description}
\item[The problem of future downgrades]
The distribution chooses to use a previous version of the package in
the next release. There is no way to indicate this, so ad-hoc
solutions such as version prefixes are used. It is
impossible to denote a future dependency that requires at least this
distribution source release in this case, either.
\item[The problem of redundant distributions]
A trivial patch has been applied to the source. While few binary
packages have been affected by this change, all binary packages
built from the source are redistributed.
\item[The problem of underdetermined rebuilds]
There have been rapid changes in the system, and although no
changes have been made to the package source, a new binary
distribution must be prepared.
\end{description}
We have devised a slightly new approach in order to alleviate these
problems. Our solution consists of encoding the history of source and
binary package developments in separate version strings we call release and
build numbers.
Since the source version is usually used by the users and developers
to identify software, we retain the notion of a source version in
P\.IS\.I as a convenience.
In the following sections, we explain the components of our
versioning scheme.
\subsection{Source Version}
Source version is the version number provided by the
upstream maintainer of the source archive used in package. It must
always be the same as the upstream version used.
\textbf{Example}: If the upstream archive name is
\emph{bash-3.0.tar.gz} the version number of the package is \emph{3.0}
\subsubsection{Version Suffixes}
There is a pre-defined list of suffixes a package version can
take.
\begin{itemize}
\item \textbf{alpha} Source/Package is in alpha state
\item \textbf{beta} Source/Package is in beta state
\item \textbf{pre} Source/Pacgage passed the beta state but stable
version is not relased yet.
\item \textbf{rc} Source/Package is a release-candidate.
\item \textbf{m} Source/Package is a milestone before stable version.
\item \textbf{p} Source/Package is released and some patches are
applied after the release. This is the patch level.
\end{itemize}
The suffix should be written after the special separator
character \textbf{\_}. And there must allways be a number after a
suffix. \textbf{Example}: packagename-1.0\_beta1
The basic order of the priorities for suffixes is:\newline
\emph{p $>$ (no suffix) $>$ m $>$ rc $>$ pre $>$ beta $>$ alpha}.
The scope of a source version string is global in the literal
sense. It shall not vary from repository to repository.
The support for these special suffixes as well as usual alphanumeric
version string ordering has been implemented in P\.IS\.I.
\section{Identifying Package Sources}
A P\.IS\.I source has three identity elements written under
\texttt{SOURCE} tag: name, source version, and source release number.
We usually say just version and release number/release instead of
source version and source release number, respectively. Name is available in
the \texttt{<Name>} tag. Version and release are available in the last
\texttt{<Update>} element of \texttt{<History>} tag of a \texttt{PSPEC}.
The name of a source package is constant throughout its revision
history. The version is the original version, given by its
programmers. Release is a positive integer. Name and release
is sufficient to uniquely identify a particular INARY source revision.
That is, version and release are independent.
\subsection{Release Number}
Release number is the number of the changes that are made to the
package source since the initial version in the distribution source. A
change can be a patch applied to the source archive, modification in
the actions.py, pspec.xml or any file in the source package
directory. This change is indicated in \texttt{<Update>} tags manually
by the package maintainer.
The initial release of a package is by default \texttt{1}. The release
number always increments by $1$ in each revision in the
\texttt{History}, even the slightest ones, but it never decrements.
The scope of the release number is a given distribution, regardless of
its version, e.g. Pardus.
In the future, INARY will have strict checks for release numbers.
\subsection{Dependency Specifications}
We allow a package to use both source version and release to identify
a particular version or a range of package versions.
\section{Identifying Binary packages}
A INARY binary package is produced from a INARY source package. It has a
name that is constant throughout the history of the source package,
and it inherits the source version and release number from the source
package. However, a binary package has in addition a binary build
number. Shortly, build number or just build. For each of the
architecture targets, e.g. particular binaries, it also has an
architecture tag.
A binary package is uniquely identified by its name, build number, and
architecture regardless of the source version.
\section{Build 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
bit change. The existence of a change is tested by comparing 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.
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 fails to provide the previous build, then a package without
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
for a particular architecture, which may vary from repository to
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}
A P\.IS\.I binary package file name contains all the components relevant
to its identification, separated by dashes:
\begin{verbatim}
<binary name>-<source version>-<source release>-<binary build>.inary
\end{verbatim}
\section{Future Work}
In the future, it may be necessary to extend the notion of release
number and build number to support branches and forks of a
distribution. A proposal was to have CVS-like branching, but it
was dismissed as unnecessary.
\end{document}
doc/prettyref.sty deleted 100644 → 0
Dosyayı görüntüle @ c5f96d5d
%%
%% This is file `prettyref.sty',
%% generated with the docstrip utility.
%%
%% The original source files were:
%%
%% prettyref.dtx (with options: `style')
%%
%% Copyright (c) 1995 Kevin Ruland
%%
%%
%% prettyref v3.0
%%
%% Copyright 1995,1998. by Kevin Ruland kevin@rodin.wustl.edu
%%
\ProvidesPackage{prettyref}[1998/07/09 v3.0]
\def\newrefformat#1#2{%
\@namedef{pr@#1}##1{#2}}
\newrefformat{eq}{\textup{(\ref{#1})}}
\newrefformat{lem}{Lemma \ref{#1}}
\newrefformat{thm}{Theorem \ref{#1}}
\newrefformat{cha}{Chapter \ref{#1}}
\newrefformat{sec}{Section \ref{#1}}
\newrefformat{tab}{Table \ref{#1} on page \pageref{#1}}
\newrefformat{fig}{Figure \ref{#1} on page \pageref{#1}}
\def\prettyref#1{\@prettyref#1:}
\def\@prettyref#1:#2:{%
\expandafter\ifx\csname pr@#1\endcsname\relax%
\PackageWarning{prettyref}{Reference format #1\space undefined}%
\ref{#1:#2}%
\else%
\csname pr@#1\endcsname{#1:#2}%
\fi%
}
\endinput
%%
%% End of file `prettyref.sty'.
doc/rst/conf.py deleted 100644 → 0
Dosyayı görüntüle @ c5f96d5d
# -*- coding: utf-8 -*-
#
# documentation build configuration file, created by
# sphinx-quickstart on Wen Feb 7 18:41:23 2018
#
# This file is execfile()d with the current directory set to its
# containing dir.
#
# The contents of this file are pickled, so don't put values in the namespace
# that aren't pickleable (module imports are okay, they're removed
# automatically).
#
# All configuration values have a default value; values that are commented out
# serve to show the default value.
import sys
import os
# pip install sphinx_rtd_theme
# import sphinx_rtd_theme
# html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
VERSION = '1.0'
AUTHOR = 'Zaryob'
# General configuration
# ---------------------
# Add any Sphinx extension module names here, as strings.
# They can be extensions
# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
extensions = ['sphinx.ext.autodoc', 'sphinx.ext.intersphinx']
# Later on, add 'sphinx.ext.viewcode' to the list if you want to have
# colorized code generated too for references.
# Add any paths that contain templates here, relative to this directory.
templates_path = ['.templates']
# The suffix of source filenames.
source_suffix = '.rst'
# The master toctree document.
master_doc = 'index'
# General substitutions.
project = 'Inary Documentation'
copyright = "2016-2017 Zaryob"
# The default replacements for |version| and |release|, also used in various
# other places throughout the built documents.
#
# The short X.Y version.
version = VERSION
# The full version, including alpha/beta/rc tags.
release = VERSION
# There are two options for replacing |today|: either, you set today to some
# non-false value, then it is used:
# today = ''
# Else, today_fmt is used as the format for a strftime call.
today_fmt = '%B %d, %Y'
# List of documents that shouldn't be included in the build.
# unused_docs = []
# List of directories, relative to source directories, that shouldn't be
# searched for source files.
# exclude_dirs = []
# A list of glob-style patterns that should be excluded when looking
# for source files.
exclude_patterns = ['modules']
# The reST default role (used for this markup: `text`) to use for all
# documents.
# default_role = None
# If true, '()' will be appended to :func: etc. cross-reference text.
# add_function_parentheses = True
# If true, the current module name will be prepended to all description
# unit titles (such as .. function::).
# add_module_names = True
# If true, sectionauthor and moduleauthor directives will be shown in the
# output. They are ignored by default.
# show_authors = False
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = 'sphinx'
highlight_language = 'YAML+Jinja'
# Substitutions, variables, entities, & shortcuts for text which do not need to link to anything.
# For titles which should be a link, use the intersphinx anchors set at the index, chapter, and
# section levels, such as qi_start_:
rst_epilog = """
"""
# Options for HTML output
# -----------------------
html_theme_path = ['../_themes']
html_theme = 'highlight'
html_short_title = 'Inary Documentation'
# The style sheet to use for HTML and HTML Help pages. A file of that name
# must exist either in Sphinx' static/ path, or in one of the custom paths
# given in html_static_path.
# html_style = 'solar.css'
# The name for this set of Sphinx documents. If None, it defaults to
# "<project> v<release> documentation".
html_title = 'Inary Documentation'
# A shorter title for the navigation bar. Default is the same as html_title.
# html_short_title = None
# The name of an image file (within the static path) to place at the top of
# the sidebar.
# html_logo = None
# The name of an image file (within the static path) to use as favicon of the
# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
# pixels large.
html_favicon = 'favicon.ico'
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
# html_static_path = ['.static']
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
# using the given strftime format.
html_last_updated_fmt = '%b %d, %Y'
# If true, SmartyPants will be used to convert quotes and dashes to
# typographically correct entities.
# html_use_smartypants = True
# Custom sidebar templates, maps document names to template names.
# html_sidebars = {}
# Additional templates that should be rendered to pages, maps page names to
# template names.
# html_additional_pages = {}
# If false, no module index is generated.
# html_use_modindex = True
# If false, no index is generated.
# html_use_index = True
# If true, the index is split into individual pages for each letter.
# html_split_index = False
# If true, the reST sources are included in the HTML build as _sources/<name>.
html_copy_source = False
# If true, an OpenSearch description file will be output, and all pages will
# contain a <link> tag referring to it. The value of this option must be the
# base URL from which the finished HTML is served.
# html_use_opensearch = ''
# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml").
# html_file_suffix = ''
# Output file base name for HTML help builder.
htmlhelp_basename = 'Poseidodoc'
# Options for LaTeX output
# ------------------------
# The paper size ('letter' or 'a4').
# latex_paper_size = 'letter'
# The font size ('10pt', '11pt' or '12pt').
# latex_font_size = '10pt'
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title, author, document class
# [howto/manual]).
latex_documents = [
('index', 'ansible.tex', 'Ansible 2.2 Documentation', AUTHOR, 'manual'),
]
# The name of an image file (relative to this directory) to place at the top of
# the title page.
# latex_logo = None
# For "manual" documents, if this is true, then toplevel headings are parts,
# not chapters.
# latex_use_parts = False
# Additional stuff for the LaTeX preamble.
# latex_preamble = ''
# Documents to append as an appendix to all manuals.
# latex_appendices = []
# If false, no module index is generated.
# latex_use_modindex = True
autoclass_content = 'both'
intersphinx_mapping = {'python3': ('https://docs.python.org/3/', (None, '../python3-3.6.2.inv')),
'jinja2': ('http://jinja.pocoo.org/docs/', (None, '../jinja2-2.9.7.inv'))}
doc/rst/en/commands/index.rst deleted 100644 → 0
Dosyayı görüntüle @ c5f96d5d
Inary Commands
==============
The All Commands
````````````````
.. toctree::
:maxdepth: 2
build.rst
check.rst
clean.rst
configure-pending.rst
delete-cache.rst
delta.rst
dist-update.rst
emerge.rst
emergeup.rst
graph.rst
index_command.rst
info.rst
list_commands.rst
orphaned_command.rst
remove.rst
repo_commands.rst
search.rst
upgrade.rst
doc/rst/en/developing_inary/index.rst deleted 100644 → 0
Dosyayı görüntüle @ c5f96d5d
Coding for Inary
==============================
.. toctree::
:maxdepth: 2
developer_roles
coding_for_inary
making_inary_packages
doc/rst/en/inary_types/index.rst deleted 100644 → 0
Dosyayı görüntüle @ c5f96d5d
Inary
=====
.. toctree::
:maxdepth: 2
about_components
about_scom_scripts
doc/rst/en/index.rst deleted 100644 → 0
Dosyayı görüntüle @ c5f96d5d
Inary Handbook
==============
About Documentation
```````````````````
Welcome to Inary documentation
This documentation about Inary package managing system.
.. _an_introduction:
.. toctree::
:maxdepth: 2
about_inary
installing_inary
inary_commands/index
inary_types/index
inary_tools/index
developing_inary/index
most_questions
This documentation licensed with GPL-3.
doc/rst/index.rst deleted 100644 → 0
Dosyayı görüntüle @ c5f96d5d
Inary Doc
===============
.. _an_introduction:
.. toctree::
:maxdepth: 2
tr/index
en/index
This documentation Licensed with GPL-3.
doc/rst/tr/commands/index.rst deleted 100644 → 0
Dosyayı görüntüle @ c5f96d5d
Inary Komutları
===============
Inary paket yönetim sistemi standart kullanıcının beklediği tüm komutları
içerdiği gibi kendine özel komutlar da içerir.
inary help diyerek bütün komutları görebilirsiniz.
.. shell::
$ inary help
usage: inary [seçenekler] <komut> [parametreler]
<komut> aşağıdakilerden birisi olabilir:
add-repo (ar) - Depo ekle
blame (bl) - Paket sahibi ve yayım bilgisi
build (bi) - Verilen INARY paket(ler)ini inşa et
check - Kurulumu denetle
clean - Kullanılmayan kilitleri temizle
configure-pending (cp) - Configure pending packages
delete-cache (dc) - Önbellek dosyalarını temizle
delta (dt) - Delta paketleri yarat
disable-repo (dr) - Depoyu pasifleştir
dist-update (distup) - Update the system a new release
emerge (em) - INARY kaynak paketlerini depodan inşa et ve kur
emergeup (emup) - INARY kaynak paketlerini depodan inşa et ve yükselt
enable-repo (er) - Depoyu etkinleştir
fetch (fc) - Paket indir
graph - Paket ilişkilerinin grafiğini çıkar
help (?) - Verilen komutlar hakkında yardım görüntüler
history (hs) - INARY işlemlerinin günlüğü
index (ix) - Index INARY files in a given directory
info - Paket bilgisini göster
install (it) - INARY paket(ler)i kur
list-available (la) - Depolardaki paketleri listele
list-components (lc) - Bileşenleri listele
list-installed (li) - Tüm kurulu paketlerin listesini bas.
list-newest (ln) - Depolardaki en yeni paketleri listele
list-orphaned (lo) - List orphaned packages
list-pending (lp) - Bekleyen paketleri listele
list-repo (lr) - Depoları listele
list-sources (ls) - Müsait kaynakları listele
list-upgrades (lu) - Yükseltilecek paketleri listele
rebuild-db (rdb) - Veritabanlarını Yeniden İnşa Et
remove (rm) - INARY paketlerini kaldır
remove-orphaned (ro) - Remove orphaned packages
remove-repo (rr) - Depoları kaldır
search (sr) - Paket ara
search-file (sf) - Dosya ara
update-repo (ur) - Depo veritabanlarını güncelle
upgrade (up) - INARY paketlerini güncelle
Belirli bir komut hakkında yardım almak için "inary help <komut>" kullanınız.
Seçenekler:
--version : programın sürüm numarasını göster ve çık
-h [--help] : bu yardım iletisini göster ve çık
genel seçenekler:
-D [--destdir] arg : INARY komutları için sistem kökünü değiştir.
-y [--yes-all] : Bütün evet/hayır sorularında cevabı evet kabul
et.
-u [--username] arg
-p [--password] arg
-L [--bandwidth-limit] arg : Bant genişliği kullanımını belirtilen kilobaytın
altında tut.
-v [--verbose] : Detaylı çıktı
-d [--debug] : Hata ayıklama bilgisini göster.
-N [--no-color] : INARY çıktılarında renk kullanılmasını engeller.
Tüm Komutlar Hakkında
`````````````````````
.. toctree::
:maxdepth: 2
build.rst
check.rst
clean.rst
configure-pending.rst
delete-cache.rst
delta.rst
dist-update.rst
emerge.rst
emergeup.rst
graph.rst
index_command.rst
info.rst
list_commands.rst
orphaned_command.rst
remove.rst
repo_commands.rst
search.rst
upgrade.rst
doc/rst/tr/developing_inary/index.rst deleted 100644 → 0
Dosyayı görüntüle @ c5f96d5d
Geliştirme Yapmak ve Katkıda Bulunmak
=====================================
Inary paket yönetim sistemi Sulin Topluluğuna bağlı olmak ile beraber
isteyen kişiler Inary'i geliştirmeye yardımcı olabilirler. Yardımcı olmak
isteyenler, paketlerini yapmak yayınlamak bizimle paylaşmak isteyenler ve
diğer tüm şeyler hakkında:
.. toctree::
:maxdepth: 2
developer_roles
coding_for_inary
making_inary_packages
doc/rst/tr/inary_types/components.rst deleted 100644 → 0
Dosyayı görüntüle @ c5f96d5d
component'larla ilgili notlar
1. Temel feature'lar (Eray)
--------------------
Iki yerde component tag'i tanimladik simdiye kadar, bir
source'larda bir de binary'lerde. Binary'de tanimlanan component default
olarak source'daki tanimi inherit ediyor ve tanimlanan component'i override
edebiliyor.
Bir component temel olarak bir meta-package, icerisinde paketler olan
bir paket. Bir component'in icerisinde bir takim source'lar ve bir takim
binary'ler bulunuyor diye bakabiliriz. Sanirim query'leri bu sekilde yapmak
mumkun olmali.
$ inary list-components
$ inary info system.base
Source packages in system.base:
....
....
Binary packages in system.base:
....
....
gibi ozellikler eklemeyi umit ediyorum.
Source'larin component tag'leri de, gene sadece bir senaryo konusuyorum,
direkt olarak directory structure'indan inherit alinacak. Ayni zamanda o pspec
icin de bir tane component tanimlananack default olarak, ve bu component o
scope'da tanimlanmis olan butun binary package'lari icerecek.
Ornegin diyelim ki a/b/c/pspec.xml var ve c1 c2 c3 seklinde uc tane paket
tanimliyor. Hic bir component tanimi yapilmadigi zaman otomatik olarak bir
a.b.c component'i olusturulacak, ve bu component'in icerisinde c1 c2 c3
bulunacak.
$ inary info a.b.c
Source packages:
c - oldur beni yarim sen olmazsan biterim
Binary packages:
c1 - bu aksam demlenmemek sonum olur benim
c2 - sincaplarla konustum butun gece
c3 - her gul gordugumde icim kan aglar
Bu varsayilan davranis, ama bunu degistirmek mumkun olacak. Burada yamuk
gozukebilecek bir sey var, o da tek bir paket oldugunda sanki biraz
redundancy olmasi, o takdirde bir optimizasyon olarak, diyelim ki
a/b/c/pspec.xml'in icerisinde tek bir paket tanimli c1
$ inary info a.b
....
c1 - dil dil dillerdeyim
olabilir bu durumda, bu genel agac mantiginda bir sorun yaratmayacaktir.
2. Temel tanım (Barış)
fiziksel aitlik: kdebase'den çıkan kcontrol gibi; grup aitliği: pdf
göstericileri gibi...
3. Database XML ayrımı (Barış)
Component database'i ile component.xml ayrı olmalı. Component database,
inary'nin inary-index.xml dosyasını okuyarak oluşturacağı bir veritabanı. Hangi
paketler hangi componentlere dahil, vs. sorguları bu veritabanından
yapılacak.
Pspec dosyasını hatırlayalım. İçerisinde bir <PartOf> diye bir tag var.
Oluşturulacak paketin hangi component'e ait olduğunu belirtiyor. Bu bilgi
inary-index.xml dosyasına da koyulmalı.
4. PL modüllerine benzerlik (Eray)
component tag'leri Java ya da python'daki gibi
directory yainaryndan cikiyor. Yani inary bir programlama dili olsaydi
component'lar module'ler ya da package'larla es anlamli olacakti.
5. Mereology ve Eray'ın açıklama çabaları (Eray)
PartOf iliskisi hakkında su kadarini soylemek yeter: eger a b'nin bir parcasiysa,
a'nin fonksiyonu b'nin fonksiyonunun bir parcasidir. Bu da fiziksel sistemler
icin bir principle of compositionality'nin varligindan hareket eder [*]
Genel olarak da software engineering ve AI camiasinda module'un tanimi gayet
iyi bilinir. Bir modul icerisindeki bagimliliklar yogundur. Moduller arasindaki
bagimliliklar zayiftir.
Bu tanim sadece software engineering'de degil, nesneler arasindaki
benzerliklerin incelendigi bir cok disiplinde kullanilan informal bir tanim,
ama tabii ki formule dokulmus bir ton hali var.Sırf bu tanımı taban alarak
yazılmış başarılı kümeleme (clustering) algoritmaları var.
Modulerlik tanimi verilen *fiziksel* modul ve parcasi olma iliskisiyle
birlesince birlikte install edilip remove edilme yahut ortak bağımlılıklara
sahip olma tanımlarına götürür.
Bu tanımı analiz edebilmek için parcasi olma iliskisininin anlamini
korumamiz yeterli. Temel olarak
  kol insanin parcasidir
iliskisi burada yer aliyor.  Eger
  a partof b
turu iliskilerde a paket ya da component, ve b component ise, a ve b'nin
iliskisinin kol ve insan iliskisi gibi olmasini bekleriz. Eger bu parca-butun
iliskisini ihlal ediyorsa o zaman muhtemelen yanlis bir iliski bulunmus
demektir.
Bunun turlu sonuclari da onem sirasina gore soyle dizilebilir:
1. Fonksiyonlarin bolunebilmesi prensibinden: (basit bir sonuç)
   a's function is part-of b's function
orneğin kolun fonksiyonu insanın total fonksiyonunun bir parçasıdır.
paket ornegi: inary'nin fonksiyonu olan paket yükleme/çıkarma system.base'in fonksiyonunun, yani temel pardus sisteminin fonksiyonunun bir parçasıdır.
2. Karmasik sistemlerde birbirine dayanan ufak parcalarin kararli yapilar
meydana getirmesi prensibinden: (evrimsel sonuç)
   if a is a part-of c, and b is a part-of c, then it follows that a and b
may:
     a. have many interdependencies
     b. share in their origins
  (which are about the same thing)
2b. sonucunun bizim durumumuza uygulanması, source code'un aynı kaynaktan
çıkması, birlikte inşa edilmeleri gibi şartları getirir. Bunun oldukça
olasi, en azindan insa metodlarinin ve kaynaklarının birbirine benzemesini
bekleriz. Yalniz, 2.a'daki bagimliliklar sadece insa ile degil ayni zamanda
calisma ile de alakalidir. Kaynakları farklı parçaların birbirine bağımlı
hale gelebilecegini unutmamak gerekir.
Fedora'nin yaklasiminin hos tarafi, boyle teknik ayrintilara girmeden "package
group" mantigini kullanmasiydi, ama bizim belli bir anlami olan parca-butun
iliskisini korumamiz daha mantikli bir yazilim ontology'si ortaya
cikaracaktir. Onlarin yaklasimi ise "anything goes", grup ile kategori'nin
temel bir farki yok cunku, herhangi bir bakis acisi olabilir "grup".
6. Modulleri test etmek (!!) (Eray)
------------------------------------
INARY'deki seçilen implementation detaylari bir tanima cok fazla commitment
yapmiyor, implementation'ın getirdiği tek şey paketleri bir ağaca koymak.
Component'ların seçiminin ne kadar kaliteli olduğunu belirleyemiyor.
Paketlerin ve componentlarin secimi yapiyor, ki kritik olan o.
Yalnız modulerlik tanimindan ve part-of iliskisinin
  if a is part of b, and b is part of c, then a is part of c.
  if a is part of b, and b is not part of c, then a is not part of c.
gibi sonuclari getirmesinden hareketle (ki bunlar klasik computational
ontology) kismen test edebilecegimiz bir sekil aliyor ornegin bagimlilik
graph'ini cluster ederek, ya da her modul icin bir modulerlik sayisi
hesaplayarak. Daha az formal olarak da bu sonuçları kafamızda yürüterek
yaptığımız componentların ne kadar akla yatkın olduğunu bulabiliriz.
7. Cagların frugalware önerisi
------------------------------
http://ftp.frugalware.org/pub/frugalware/frugalware-current/source/
adresindeki yerleşimin hem source hem de binary depo için uygulanmasını ve
kategori, componentların da bundan çıkartılmasını öneriyorum.
doc/rst/tr/inary_types/index.rst deleted 100644 → 0
Dosyayı görüntüle @ c5f96d5d
Inary'e Ait Tanımlar
====================
.. toctree::
:maxdepth: 2
about_components
about_scom_scripts
doc/rst/tr/index.rst deleted 100644 → 0
Dosyayı görüntüle @ c5f96d5d
Inary El Kitabı
===============
Dokumantasyon Hakkında
``````````````
Inary documentasyonuna hoş geldiniz.
Bu dokumantasyon Inary paket yönetimi hakkında tüm bilgileri vermektedir.
.. _an_introduction:
.. toctree::
:maxdepth: 2
about_inary
installing_inary
inary_commands/index
inary_types/index
inary_tools/index
developing_inary/index
most_questions
Bu dokumantasyon AGPL-3 ile lisanslanmıştır.
doc/rst/tr/installing_inary.rst deleted 100644 → 0
Dosyayı görüntüle @ c5f96d5d
Inary Packet Yöneticisinin Kurulumu
===================================
Inary paket yöneticisi üç farklı şekilde kurulabilir:
* Tam Kurulum: Sistemde tek başına bütün paket işlerini inary yapar ve sistemde
bulunan tüm paketleri analiz edip mevcut kuruluma dokunmadan tüm kurulu
uygulamalarınızı otomatik olarak inary veritabanına işler. Tercihe bağlı olarak
diğer paket yönetim yazılımlarını siler.
* Sınırlandırılmış Kurulum: Kurulum yapılan kullanıcının kendi home dizini altında
inary paketlerini kurup kaldırmasına olanak tanıyan bir kurulum çeşitidir.
Sınırlandırılmış kurulumda sistemde mevcut başka bir paket yönerim yazılımı var
ise dokunmaz, hiçbir dosya işlemi kök dizin altında yapılmaz ve inary ile yapılan
tüm işler '~/.inary' dizini silinerek yok edilebilir.
* Portable Kurulumu: Herhangi başka bir yazılıma ihtiyaç duymadan inary ve python3'ün
MacOS, Solaris ve benzeri sistemlerde tek tıkla kurulumuna olanak verir. Geriye
kalan tüm özellikleri sınırlandırılmış kurulum ile aynıdır
.. note:: Inary paket yöneticisi herbir kurulum şekli için ayrı bir paket
deposu içerir. Kurulum şeklinize uygun depo kullanmanız önemle rica edilir.
Tam Kurulum
```````````
Eğer geliştirilen son sürümü kullanmak istiyorsanız
.. code-block:: shell
git clone https://git.sulin.org/inary.git
sudo python3 setup.py install
inary-rebuild-system
inary rdb
Eğer mevcut bulunan en kararlı sürümü kullanmak istiyorsanız
.. code-block:: shell
wget https://sulin.org/inary/download/lastest.tar.gz
tar xvf lastest.tar.gz
cd inary/
sudo python3 setup.py install
inary-rebuild-system
inary rdb
.. note:: setup.py scripti ile kurulum yaparken otomatik olarak
tüm bağımlılıklar internet üzerinden indirilir.
Sınırlandırılmış kurulum
````````````````````````
Eğer geliştirilen son sürümü kullanmak istiyorsanız
.. code-block:: shell
mkdir ~/.inary
git clone https://git.sulin.org/inary.git
python3 setup.py build
python3 setup.py install --root=~/.inary
inary rdb
Eğer mevcut bulunan en kararlı sürümü kullanmak istiyorsanız
.. code-block:: shell
mkdir ~/.inary
wget https://sulin.org/inary/download/lastest.tar.gz
tar xvf lastest.tar.gz
cd inary/
python3 setup.py build
python3 setup.py install --root=~/.inary
inary rdb
Portable kurulum
````````````````
.. code-block:: shell
wget https://sulin.org/inary/download/portable.tar.gz
tar xvf portable.tar.gz
mv portable ~/.inary
inary rdb
Inary'i Güncelleştirmek
```````````````````````
Inary kullandığınız inary'i kullanarak güncelleştirmeye olanak verir.
.. code-block:: shell
inary ur
inary up inary
Scom Kullanmadan Paket İşlemi Yapmak
````````````````````````````````````
Inary paket yönetim sistemi eski inary bağımlılığı olan ve pisi paket konfigurasyon
betiklerini içerisinde bulunduran comar sistemini forklayıp geliştirmiştir.
Ancak mevcut inary eskiden farklı olarak scom kullanmadan paket işlemi yapmaya
olanak verir. Ancak bu durumda paketlerin kurulumundan sonraki konfigurasyon
tamamen kullanıcıya bırakılmıştır.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment