Nasıl Nasıl Olur

ApiPlan

@@ -2,8 +2,8 @@ API Plan
 ========
 
 Inary does not have a usable api. All the projects use its internal modules to do their
-jobs. This file holds a list of these usages by project as a guide for a new competent 
-pisi api.
+jobs. This file holds a list of these usages by project as a guide for a new competent
+inary api.
 
 Inary
 ====
@@ -64,7 +64,7 @@ api.
 
 * repodb.get_repo
 * packagedb.get_package
-  pm still uses the old packagedb with pisi.itemsbyrepo.installed or pisi.itemsbyrepo.repos params
+  pm still uses the old packagedb with inary.itemsbyrepo.installed or inary.itemsbyrepo.repos params
 * componentdb.list_components
 * repodb.list
 * componentdb.get_union_comp
@@ -109,7 +109,7 @@ Below are the inary modules used internally by PackageKit.
 * api.upgrade
 * api.remove
 * api.list_upgradable
-* api.update_repo 
+* api.update_repo
 * api.list_repos
 * repodb.get_repo.indexuri.get_uri
 * version.Version

CODING

@@ -4,19 +4,19 @@ Like every serious project, there are guidelines.
 Guidelines
 ----------
 
-0. Before reading any further please observe 
-   PEP 8: Style Guide for Python Code 
+0. Before reading any further please observe
+   PEP 8: Style Guide for Python Code
    http://www.python.org/peps/pep-0008.html
 
    In particular this means no lameCaps
 
 1. When using dirnames, don't expect the dir to end
    with a trailing slash, and please use the dirnames
-   in pisiconfig. Use util.join_path instead of os.path.join
+   in inaryconfig. Use util.join_path instead of os.path.join
 2. Python indentation is usually 4 spaces.
 3. Follow python philosophy of 'batteries included'
 4. Use exceptions, don't return error codes
-5. Don't make the PISI code have runtime dependencies on
+5. Don't make the INARY code have runtime dependencies on
    a particular distribution (as much as possible).
 6. Don't assume narrow use cases. Allow for a mediocre
    amount of generalization in your code, for pieces that
@@ -25,7 +25,7 @@ Guidelines
    breaks anything and fix breakage. For instance a
    name. Running the tests is not always enough!
 8. A good design ensures separation of concerns. Every module
-   has a specific documented responsibility. Don't make the 
+   has a specific documented responsibility. Don't make the
    horse clean your windows.
 9. To ensure readability avoid nesting python constructs
    more than 3 levels deep. Python is a good language (unlike C),
@@ -36,7 +36,7 @@ Guidelines
 10. Use a particular abstraction like a class or function only
    if it makes sense. Don't just define things because they can
    be defined. Define only things that will/may be used.
-11. If you are doing an expensive task like searching through 
+11. If you are doing an expensive task like searching through
    10000 text chunks, please use an efficient data structure
    and algorithm. We are not MS engineers who know no data
    structure beyond doubly linked lists and no algorithm beyond
@@ -50,10 +50,10 @@ Guidelines
 Branches and SVN
 ----------------
 
-There are two branches of pisi, one is called pisi-devel and 
-new features that are large enough to cause instability go 
+There are two branches of inary, one is called inary-devel and
+new features that are large enough to cause instability go
 into that branch. The trunk version is supposed to be stable at
-all times. This means that you *must* run unit tests and other 
+all times. This means that you *must* run unit tests and other
 test scripts after committing any change that cannot be tested
 in isolation. Run the unit tests periodically to catch unseen
 bugs. A release from the stable branch *must not* break any tests
@@ -123,7 +123,7 @@ object, why replicate everything in the upper level? If
 the semantics prevents dependency changes, then chains
 of 3 or even 4 could be acceptable.
 
-OTOH, in Python and C++, it's not always good to implement 
+OTOH, in Python and C++, it's not always good to implement
 accessor/modifier pairs for every property of an object.
 It would be much simpler if you are not doing any special
 processing on the property (e.g. if what the type system
@@ -134,18 +134,18 @@ putting more than, say, 10 methods in a class. That works
 really well in practice, forcing refactoring every now
 and then.
 
-2. We all know, you're using LISP but didn't want to tell 
+2. We all know, you're using LISP but didn't want to tell
 us. Don't be scared, as a success story and for your encouragment
 there are tens of people somewhere with LISP releated jobs.
 
 3. If you are studying Data structures and Algorithms, and if
-your first assignment is to implement a basic FIFO queue,  
+your first assignment is to implement a basic FIFO queue,
 don't implement it. Just show your teacher the syntax of LISP,
 tell him how beautiful it is, and show how an autistic person
-can count lots of parenthesis with a "one second" look, you'll 
+can count lots of parenthesis with a "one second" look, you'll
 probably get A+.
 
-4. If you are interested in "Playstation 2 Linux Games Programming" 
+4. If you are interested in "Playstation 2 Linux Games Programming"
 or "How to extend C programs with Guile", please don't exercise
 your valuable skills in this project.
 

HISTORY.devel-fork

@@ -4,7 +4,7 @@ HISTORY OF THE DEVELOPMENT BRANCH FORK
 
 1. Introduction
 
-PISI was the Pardus Linux package manager, I wrote most of it while
+INARY was the Pardus Linux package manager, I wrote most of it while
 working at TUBITAK/UEKAE during 2005-2006 as a researcher, and it took
 me about half a year to write it, and another half year to revise it
 (80-90% of commit numbers/size), save for build commands, and the
@@ -18,13 +18,13 @@ author). The latter releases do not have much that is new added to the
 code, they've only stripped down some features and commands like the
 search API. They've also tried to remove my name from the AUTHORS list
 and from individual sources, in an attempt to hide my contributions,
-pretending that PISI was written collaboratively. It was not. I wrote
-most of it, I was the only seasoned programmer who worked on PISI,
+pretending that INARY was written collaboratively. It was not. I wrote
+most of it, I was the only seasoned programmer who worked on INARY,
 amazingly, it turns out that it does take some skill to design an
 efficient system tool; I was also one of the few ones who weren't
 overtly lazy and did not spend the entire day writing blogs about
 irrelevant stuff and drinking tea and tobacco like a state
-officer. The Turkish Linux Users Group award for PISI was also given
+officer. The Turkish Linux Users Group award for INARY was also given
 to me personally, not the team. I left the award trophy as a gesture
 of kindness to promote team unity. Since I am not pleased with the
 later Pardus release branch that I find to be desecrating my poetic
@@ -33,11 +33,11 @@ last development branch I found on my local SVN copies, out of
 1.1_beta12. The next release will be 1.2, and then the next major
 revision will be called 3.0. I declare the 1.0 and 1.1 releases
 and 2.x branch from TUBITAK, which is not truly a major revision to
-PISI code, to be obsolete. May its bits rot in peace.
+INARY code, to be obsolete. May its bits rot in peace.
 
 To be absolutely clear, the last release I committed was 1.1beta9,
 and it may be found here:
-https://github.com/pars-linux/pisi/tree/3f94e538ec14b945271b5123efcabe934b1bbdb6
+
 
 You will find that there have not been many interesting additions since then,
 save for some code reorganization that moved files and functions around.
@@ -45,10 +45,10 @@ I noticed that most of the latter changes amount to crippleware, and
 I am only selectively backporting some stuff like mirror support for the sake
 of backwards (back to the future?) compatibility.
 
-2. Novelties in PISI
+2. Novelties in INARY
 
 There are two very interesting generic python novelties I developed
-for PISI. The use of metaclasses was essential to both. The first one
+for INARY. The use of metaclasses was essential to both. The first one
 is something I call autoxml, and it uses python metaclasses to work
 with XML based configuration using Berkeley DB, but the DB is
 completely abstracted. It's basically a neat nosql python XML/DB
@@ -57,14 +57,14 @@ metaclasses, which also worked beautifully. The algorithms are also
 pretty compact. I designed and implemented some graph algorithms to
 deal with dependency resolution, and so forth. These algorithms make a
 pretty useful library, you can write a lot of effective package tools
-around the PISI framework, as we proved in the server scripts of
+around the INARY framework, as we proved in the server scripts of
 Pardus GNU/Linux distribution.
 
-PISI also has some features not found in any other package manager
+INARY also has some features not found in any other package manager
 that I know of, such as the ability to work with hierarchical
 components and metadata information in a clean, non-kludgey way, and
 the smooth merging of binary and source package approaches of debian
-and gentoo. PISI is sort of like gentoo package tools ported to debian
+and gentoo. INARY is sort of like gentoo package tools ported to debian
 and debian package tools ported to gentoo, and rewritten in python in
 a better way. Admittedly, there are some missing features, the
 handling of virtual packages leaves something to be desired, I really
@@ -76,20 +76,20 @@ contribution. Caglar's actionsapi was also quite nice, Caglar was very
 hard working, he developed most of the packages himself. Baris
 contributed some nice bugfixes and developed most of the build path,
 which does something a lot like gentoo. Getting both the binary and
-source packages work seamlessly was an important feature of PISI, and
+source packages work seamlessly was an important feature of INARY, and
 again, not really found in any other package manager the way it is in
-Pardus. Although more than 10 years old, I suspect, PISI remains the
+Pardus. Although more than 10 years old, I suspect, INARY remains the
 most compact, featureful and efficient package manager of all.
 
-3. PISI Design
+3. INARY Design
 
-The design of PISI was based on a document about an XML format
+The design of INARY was based on a document about an XML format
 designed by Pardus developers before I joined the team. I saw that it
 is basically the same thing as dpkg, so I made a minor revision to the
 document, and added a whole lot of features that I had designed as an
 addition to dpkg / apt-get, such as the ability to deal with source
 packages in the right way, the unique versioning / revisioning schema
-of PISI, package / component / is-a models, dependency system, and
+of INARY, package / component / is-a models, dependency system, and
 proposed to write the project in python. The most critical design and
 features belong to me, such as the XML based data structures, autoxml,
 the databases, the graph and dependency algorithms, the commands, the
@@ -101,31 +101,31 @@ comprehensions and metaclasses did something for me, after all.
 4. Development branch goals
 
 The development branch's goal is to make the Pardus dependencies
-optional. My vision for PISI was beyond Pardus, I had designed it as a
+optional. My vision for INARY was beyond Pardus, I had designed it as a
 replacement for dpkg. It can replace dpkg/apt-get in a debian based system,
 or gentoo package manager in a gentoo based system, with some due
 effort, of course. Because of their sheer incompetence, TUBITAK later
-dropped the PISI based Pardus distribution unwittingly and replaced it
+dropped the INARY based Pardus distribution unwittingly and replaced it
 with a Debian based distribution, when what they really needed was a
 competent development team that could improve the, IMHO quite
 satisfactory, system tools. However, the heart of Pardus is still the
-PISI package manager, and naturally the other system tools such as
-Gurer's COMAR and MUDUR, Baris's YALI. Those four tools + PISI packages make
+INARY package manager, and naturally the other system tools such as
+Gurer's COMAR and MUDUR, Baris's YALI. Those four tools + INARY packages make
 a Pardus distro. I will not bother trying to rewrite COMAR and YALI,
-but I have other ideas that will make PISI a portable package manager,
+but I have other ideas that will make INARY a portable package manager,
 which is most of the reason I decided to write it in python. There are,
 however, distros that are Pardus derivatives, and I will make a good
-effort to support them with a reference implementation of PISI that
+effort to support them with a reference implementation of INARY that
 they can use or derive from.
 
 5. Remarks
 
 Let me know what you want to call the package manger in English, I'm
 considering various alternatives. Kitty, and pussy are among the names
-I'm considering. PISI means Packages Intended Successfully as
-Intended, but I made that up as a de-acronym for PISI which is an
+I'm considering. INARY means Packages Intended Successfully as
+Intended, but I made that up as a de-acronym for INARY which is an
 affectionate word for a cat in Turkish (like pussy), which was a name
 decided before I even designed the code, çomar likewise is a slang for
-dog in Turkish. I love my PISI, of course. <3
+dog in Turkish. I love my INARY, of course. <3
 
 Happy hacking! :3

INSTALL

@@ -5,11 +5,10 @@ You can install Inary on your system with a single command.
 If you are on a Solus or PisiLinux system, you should delete /usr/lib/pardus/pisi
 when you are installing the SVN version
 
-Inary requires piksemel XML processing library, Pardus configuration 
+Inary requires Pardus configuration 
 manager based SCOM and SCOM API in order to run.
 
-If you are upgrading from an old INARY release you may have to 
+If you are upgrading from an old INARY release you may have to
 run the following command as root:
 
 # inary rebuild-db
-

ROADMAP

-PiSi TODO List
+Inary TODO List
 ==============
 A list of tasks to accomplish, organized into priority sections
 
 Legend:
-- Todo 
-? Not determined if/how we have to do 
-/ In progress 
-+ Accomplished  
+- Todo
+? Not determined if/how we have to do
+/ In progress
++ Accomplished
 
-1. Pre-Alpha  
+1. Pre-Alpha
 
   + reading spec file
   + writing
@@ -34,14 +34,14 @@ Legend:
   + command line interface
     + inary-build
     + inary-install
-    + inary-index 
-    + inary-updatedb 
+    + inary-index
+    + inary-updatedb
   + single repository index
   + simple dependency checking
-  + Package/Files  
+  + Package/Files
 
-2. Alpha   
-  + multi-package dependency analysis (eray)   
+2. Alpha
+  + multi-package dependency analysis (eray)
     + design a package operation planner
     + install/remove operations (eray)
   + command line interface:
@@ -50,10 +50,10 @@ Legend:
   + configuration file
     + define the format of the configuration file
     + extend Config module (config.py) accordingly
-    + define configuration keys (baris - meren) 
+    + define configuration keys (baris - meren)
   + query
     + list of installed packages (eray)
-  + refactor actionsAPI (caglar) 
+  + refactor actionsAPI (caglar)
   + fix xml indentation (meren)
   + define file types (doc, executable, conf, etc...) (baris - meren)
   + write specfile (eray)
@@ -61,9 +61,9 @@ Legend:
   + implement file uri
     + extend the modules dealing with files accordingly
   + ui module improvements
-  + methods for interaction (yes, no questions, etc.)  
-  + implement source database (eray) 
-  + easy package preparation   
+  + methods for interaction (yes, no questions, etc.)
+  + implement source database (eray)
+  + easy package preparation
     ? convert ebuild to inary
   + Configuring system interface after installing
     + what do we need to specify in a package
@@ -93,8 +93,8 @@ Legend:
       - return meaningful localtext summaries and descriptions (Hak getire)
     + revised interface
     / Error handling
-      + improved error handling, check routines, hooks, format/print routines 
-      / write a meaningful traceback output 
+      + improved error handling, check routines, hooks, format/print routines
+      / write a meaningful traceback output
     + xmlfile support (read/write)
     + string member, in addition to tag/attribute members
     + replace specfile with new specfile using autoxml
@@ -105,13 +105,13 @@ Legend:
     + requirementsu
     + xml format, add to PSPEC
   + index component.xml's and make use of them in build
-  + a database of components: 
+  + a database of components:
       + query components by name
       + query list of packages in a component
       + index: update component database(s)
       + bug fixing
     + install/remove/upgrade components
-    + safety switch: preserve system.base, install system.devel for build, etc. 
+    + safety switch: preserve system.base, install system.devel for build, etc.
     + info <component>
     + started documentation
   + component dependencies
@@ -125,11 +125,11 @@ Legend:
     - resume file downloading (Darara.... fetcher will rewrite with httplib) (Zaryob)
   + search-file command (eray)
   + exception handling (eray)
-    + uniform exception hierarchy 
+    + uniform exception hierarchy
     + proper handling
   + API: we even have application users (eray)
     + a facade module inary.api  (eray)
-    + clean unuseful inary.api functions 
+    + clean unuseful inary.api functions
     + a library init command (eray)
     + high-level package ops, index (eray)
     + info/util commands (eray)
@@ -154,7 +154,7 @@ Legend:
     + metaclass coolness for CLI command framework (eray)
     + i18n support
       + translations and correct language for summary, description (packagers)
-      + make pisi messages translatable (eray)
+      + make inary messages translatable (eray)
       + .pot support for dist script (gurer)
       / translate messages mesajların çevirisinin yapılması (inary tr.po) (eray)
       + proper unicode handling in code - tons of fixes (eray - baris)
@@ -177,33 +177,33 @@ Legend:
       + system-wide upgrade (upgrade-all) komutu
     + incremental build (eray)
       + generate binary release number by comparing MD5s (eray)
-      + keep track of successfully completed configure, make, install steps 
+      + keep track of successfully completed configure, make, install steps
       (necessary for large-scale builds?) (meren)
-    + database locking bugs (eray)  
+    + database locking bugs (eray)
 
     + SHOULD WORKING UNDER FIXME PARTS
 
-4. Release  
-  * high priority 
+4. Release
+  * high priority
     + transaction stuff for database (eray)
-    + database version file 
-  * low priority 
+    + database version file
+  * low priority
     + search command: (eray)
     + implement an inverted index
-    + search in summary and description  
+    + search in summary and description
 
-5. Post Release 
-  * high priority  
+5. Post Release
+  * high priority
     - refactoring
-    sort of match the refactoring of pisi-2.x series and improve it 
+    sort of match the refactoring of inary-2.x series and improve it
 
-    - accelerate search  
-    / package signing    
+    - accelerate search
+    / package signing
       / an embebed package signer.(aquila)
-      + a flag to sign package after building   
-      / code to check if the package has a valid signature  
-    - cli improvements    
-      - non interactive mode (similar to --auto in urpmi)  
+      + a flag to sign package after building
+      / code to check if the package has a valid signature
+    - cli improvements
+      - non interactive mode (similar to --auto in urpmi)
     / high-level build commands
       + an emerge command, just for fun
         + make use of binary repo to satisfy dependencies in emerge
@@ -213,18 +213,18 @@ Legend:
         ? build-all (or build-distro) command, or as a separate tool
     + make a package and sourcedb for each repo
       + packagedb
-      + sourceb  
+      + sourceb
     ? improve url support: consider adding "other" protocols
-      - removable media: media://   
+      - removable media: media://
       - ftp support
-  * medium priority   
-    - UI impl: non-interactive use that selects defaults and logs output 
-    - UI impl: a general purpose Qt or GTK UI  
+  * medium priority
+    - UI impl: non-interactive use that selects defaults and logs output
+    - UI impl: a general purpose Qt or GTK UI
     / multi-architecture support
-      + design decisions 
+      + design decisions
       + extend XML specs to support that
       - cross-platform building support
-      - incremental build/fetch for repository index (pisi-index.xml)
+      - incremental build/fetch for repository index (inary-index.xml)
     / xdelta support (caglar)
       - diffsets
     / a useful distupdate command
@@ -233,17 +233,17 @@ Legend:
     - a command (check-repo) to check if repos are consistent wrt dep relations
     - component improvements (optional)
       - maintain a list of components each component has
-      - maintain a list of packages 
+      - maintain a list of packages
     - more support for categories:
       - put categories into a database
-      - fast search for categories   
-  * low priority  
+      - fast search for categories
+  * low priority
     / overhaul installdb (try to merge its use with packagedb) (eray)
     / verify metodlari
       + SpecFile
       + MetaData
       + Files
-      / Index (somebody should write one :} ) 
+      / Index (somebody should write one :} )
     - autoxml:
       - revise error checking, printing and tests
       - uri type
@@ -259,6 +259,3 @@ Legend:
         - research if there are language independent phonetic encodings
         - implement as an option (or make it possible to turn it off if it works well :))
     - fault tolerant search in package names (somehow)
-
-
-

RefactorPlan

@@ -40,25 +40,25 @@ There is even a file.py module!
 
 ==> exceptions
 * Current model is bad. Exception names should tell what is the error type. Instead
-we have one Error exception in every module. If I call pisi.api.install("lala"),
-I should get pisi.api.PackageNotFound or pisi.install.PackageNotFound or something
-like that. For every kind of error, you get pisi.api.Error now, and only way to find
+we have one Error exception in every module. If I call inary.api.install("lala"),
+I should get inary.api.PackageNotFound or inary.install.PackageNotFound or something
+like that. For every kind of error, you get inary.api.Error now, and only way to find
 out exact error is try to parse error string (which is localized).
 
 * class Exception(Exception) is evil.
 
-* There shouldn't be a bare Except: clause in pisi modules.
+* There shouldn't be a bare Except: clause in inary modules.
 
 
 ==> database
 * We should have a DB performance test suite to find important points to make faster,
-if we cannot measure, we cannot improve. 
+if we cannot measure, we cannot improve.
 
 ==> class attributes
 * In some classes there are some attributes assigned but never
 used. (see remove_unused_attributes.patch)
 
-* PiSi uses heavy classes and creates thousands of instances of them
+* Inary uses heavy classes and creates thousands of instances of them
   (Package, Metadata, Dependency, ...). These classes should define
   __slots__ to reduce the heap used.
 
@@ -71,7 +71,7 @@ used. (see remove_unused_attributes.patch)
 * ActionsAPI still needs an updated API document
 
 
-==> PiSi API
+==> Inary API
 * Write a real one
 
 
@@ -85,12 +85,12 @@ http://liste.uludag.org.tr/uludag-commits/2007-February/010070.html
 
 ==> Logging
 
-* Improve logging with all needed update/downgrade/install/remove information so one can easily find the history of packages, 
-currently PiSi wrotes everyting into logs which is not usefull. Also this information can be used for rollback and reporting.
+* Improve logging with all needed update/downgrade/install/remove information so one can easily find the history of packages,
+currently Inary wrotes everyting into logs which is not usefull. Also this information can be used for rollback and reporting.
 
 ==> function code lengths
 
-* we have some functions that goes pages long... divide all of them to small digestable chunks.. 
+* we have some functions that goes pages long... divide all of them to small digestable chunks..
   avoid writing functions longer than your editor's screen.
 
 ==> assertions
@@ -101,10 +101,9 @@ currently PiSi wrotes everyting into logs which is not usefull. Also this inform
 
 * When trying to install a package or looking for a dependency for a package the first found package
   in "repo order" is used. This design decision is not very good. When a new repo that has the latest
-  version of any package is added and if it is the last repo in order, pisi can not upgrade to this 
-  package. 
+  version of any package is added and if it is the last repo in order, inary can not upgrade to this
+  package.
 
   We can remove this order thing and in this situation we can use the latest version of the package.
-  This should also lead to some other problems but between these two not very good solutions this 
+  This should also lead to some other problems but between these two not very good solutions this
   seems to be the better one.
-

doc/dependency.tex

-%%% Local Variables: 
+%%% Local Variables:
 %%% mode: latex
 %%% TeX-master: t
-%%% End: 
+%%% End:
 
 \documentclass[a4paper,11pt]{article}
 \usepackage{graphicx}
@@ -23,7 +23,7 @@
 %\newrefformat{tab}{Table~\ref{#1}}
 %\newrefformat{fig}{Figure~\ref{#1}}
 %usepackage[active]{srcltx}
-\title{ Dependency Resolution in PISI}
+\title{ Dependency Resolution in INARY}
 
 \author{Eray \"{O}zkural}
 
@@ -77,7 +77,7 @@ edges incident to members of $A$.
 
 The dependency resolution problem may be viewed as a simple forward
 chaining problem, where we would like to begin from an initial state
-$S_0$ and by following allowable system transitions $t_i: S \to S$, 
+$S_0$ and by following allowable system transitions $t_i: S \to S$,
 arrive at a desired system state $S_f$ (where $S$ is the set of all states).
 
 A system state $S_i$ is defined as the set of installed packages on
@@ -86,7 +86,7 @@ the system together with their versions, i.e. $S_i = \{ (x,v) : x
 $t_i$ chains one system state into another, making one ACID change on
 the system. The usual atomic transitions are the single package
 install, remove and reinstall (upgrade or downgrade) operations found
-in low-level package management code of PISI. Note that in PISI, an
+in low-level package management code of INARY. Note that in INARY, an
 upgrade operation is identical to a remove operation followed by an
 install operation (which sets it apart from some other packaging
 systems).
@@ -103,12 +103,12 @@ replace the pair $(x,v)$ with $x$ in the definitions for simplicity.
 
 It is worth mentioning here the concept of system consistency. As in a
 database transaction, it is not acceptable that the system violates an
-invariant afterwards. In the context of PISI, system consistency is
+invariant afterwards. In the context of INARY, system consistency is
 composed of two conditions for the current set of installed packages.
 \begin{enumerate}
 \item All package dependencies are satisfied (we may call this a
   closed system)
-\item No package conflicts are present. 
+\item No package conflicts are present.
 \end{enumerate}
 
 Therefore, by atomic transition we also mean one that does not corrupt
@@ -123,7 +123,7 @@ solved with topological sorting. This form is not concerned with
 versions. Neither do we consider remote repositories.  From an initial
 set of packages $S_0$, we would like to install in addition a new set
 $A$ of packages obtaining $S_f = S_0 \cup A$, for a static set of package
-relations. 
+relations.
 
 The only relations considered are of the form: $a$ Depends on $b$, or
 more briefly $aDb$. The graph of all such simple dependency relations
@@ -176,7 +176,7 @@ are installed. Thus, this yields a consistency-preserving plan.
 
 \subsection{Dependency conditions}
 
-In the PISI specification, we allow a dependency to specify a local
+In the INARY specification, we allow a dependency to specify a local
 condition, for instance a program may require a dependency on
 \texttt{libx} with pardus source release $3$ or greater. Another
 program may require a dependency on a particular source release. These
@@ -199,7 +199,7 @@ $P(v)$.
 
 \subsection{Conflicts and COMAR dependencies}
 
-The tags \texttt{Conflicts} and \texttt{Provides} in PISI are
+The tags \texttt{Conflicts} and \texttt{Provides} in INARY are
 inherited from Debian distribution. A conflict between two packages
 ($a$ conflicts with $b$) is a symmetric relation that prevents the
 packages $a,b$ from being installed simultaneously (It is
@@ -207,7 +207,7 @@ sufficient that only one direction of the relation is declared, the
 other direction is inferred). Provision in the form of $a$ provides $A$
 denotes that $a$ implements a virtual package abstraction $A$.
 
-In PISI, a package can provide an object of a COMAR Object Model (OM),
+In INARY, a package can provide an object of a COMAR Object Model (OM),
 and is currently the only model of a ``virtual package''. In the
 following example, let $a_1,a_2,\ldots,a_n$ provide the OM $A$. A package
 can depend on another package's OM, for instance $b$ comar-depends on
@@ -246,7 +246,7 @@ topological order rather than installing packages in the reverse
 topological order.
 
 \section{Remote repositories and upgrade operation}
- 
+
 
 The upgrade operation is more complicated. First of all, the system
 has to distinguish between the current relation graph (e.g.
@@ -261,8 +261,8 @@ two graphs, then the declarations made by the package are one and the
 same.
 
 $G_0$ can be calculated from the package information (e.g. metadata)
-of the installed packages and is stored by PISI in a dedicated
-database. $G_f$ is most likely constructed from a PISI Index file
+of the installed packages and is stored by INARY in a dedicated
+database. $G_f$ is most likely constructed from a INARY Index file
 corresponding to a particular package repository. Accessing both of
 these entities is expensive and we should take care to minimize access
 as in the previous section.
@@ -378,4 +378,3 @@ plan:\\
   remove $(c,2)$\\
   remove $(a,2)$\\
 \end{document}
-

doc/package_versions.tex

@@ -18,7 +18,7 @@ detailed Source Version Section, and started the Section on Release Number.
 
 \section{Introduction}
 
-This document explains the \emph{version policy} that applies to 
+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
@@ -42,7 +42,7 @@ 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 
+changes have been made to the package source, a new binary
 distribution must be prepared.
 
 \end{description}
@@ -54,7 +54,7 @@ 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. 
+P\.IS\.I as a convenience.
 
 In the following sections, we explain the components of our
 versioning scheme.
@@ -62,7 +62,7 @@ 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 
+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
@@ -108,8 +108,8 @@ the \texttt{<Name>} tag. Version and release are available in the last
 
 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 PISI source revision.
+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}
@@ -128,7 +128,7 @@ number always increments by $1$ in each revision in the
 The scope of the release number is a given distribution, regardless of
 its version, e.g. Pardus.
 
-In the future, PISI will have strict checks for release numbers.
+In the future, INARY will have strict checks for release numbers.
 
 \subsection{Dependency Specifications}
 
@@ -137,7 +137,7 @@ a particular version or a range of package versions.
 
 \section{Identifying Binary packages}
 
-A PISI binary package is produced from a PISI source package. It has a
+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
@@ -164,9 +164,9 @@ 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 
+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  
+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}
@@ -174,7 +174,7 @@ given package and architecture is unique in a given repository.
 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>.pisi
+  <binary name>-<source version>-<source release>-<binary build>.inary
 \end{verbatim}
 
 \section{Future Work}

doc/rst/tr/installing_inary.rst

@@ -19,7 +19,7 @@ Inary paket yöneticisi üç farklı şekilde kurulabilir:
   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 
+.. 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.
 
 
@@ -93,10 +93,8 @@ Inary kullandığınız inary'i kullanarak güncelleştirmeye olanak verir.
 
 Scom Kullanmadan Paket İşlemi Yapmak
 ````````````````````````````````````
-Inary paket yönetim sistemi eski pisi bağımlılığı olan ve pisi packet konfigurasyon
+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 
+olanak verir. Ancak bu durumda paketlerin kurulumundan sonraki konfigurasyon
 tamamen kullanıcıya bırakılmıştır.
-
-

inary/cli/check.py

@@ -136,7 +136,7 @@ class Check(command.Command, metaclass=command.autocommand):