moparisthebest
/
pacman
mirror of https://github.com/moparisthebest/pacman
1
0
Fork 0
Code Issues Releases Wiki Activity

Small changes to README, mostly just to postpone making any real changes. :)

This commit is contained in:
Dan McGee 2007-02-08 05:58:11 +00:00
parent 2df13b6e8f
commit a97bb3e279
1 changed files with 28 additions and 49 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

77
README
View File

@ -1,58 +1,37 @@
==========================================================================
README:
Overview and internals of the ALPM library and the PACMAN frontend.
This document describes the state of the implementation before its CVS
import.
At this stage, the code is in pre-alpha state, but the design should not
change that much.
There's still need for some work to get the current code properly working.
The tag "ORE" was added in various places in the code, each time a point
remains unclear or is not yet implemented.
==========================================================================
ALPM library overview & internals ALPM library overview & internals
================================= =================================
Here is a list of the main objects and files from the ALPM (i.e. Arch Here is a list of the main objects and files from the ALPM (i.e. Arch Linux
Linux Package Management) library. Package Management) library. This document, whilst not exhaustive, also
This document, whilst not exhaustive, also indicates some limitations indicates some limitations (on purpose, or sometimes due to its poor design) of
(on purpose, or sometimes due to its poor design) of the library at the the library at the present time.
present time.
Note: there is one special file ("alpm.h") which is the public interface There is one special file,"alpm.h", which is the public interface that
that should be distributed and installed on systems with the library. should be distributed and installed on systems with the library. Only
Only structures, data and functions declared within this file are made structures, data and functions declared within this file are made available to
available to the frontend. the frontend. Lots of structures are of an opaque type and their fields are
Lots of structures are of an opaque type and their fields are only only accessible in read-only mode, through some clearly defined functions.
accessible in read-only mode, through some clearly defined functions.
Note: several structures and functions have been renamed compared to In addition to "alpm.h", the interfaces of "alpm_list.h" have also been made
pacman 2.9 code. available to the frontend. It is not a requirement for the frontend to use
This was done at first for the sake of naming scheme consistency, and these list functions; however, it prevents frontends from having to reimplement
then primarily because of potential namespace conflicts between library possibly useful functions.
and frontend spaces.
Indeed, it is not possible to have two different functions with the same
name declared in both spaces.
To avoid such conflicts, some function names have been prepended with
"_alpm_".
In a general manner, public library functions are named
"alpm_<type>_<action>" (examples: alpm_trans_commit(),
alpm_lib_release(), alpm_pkg_getinfo(), ...).
Internal (and thus private) functions should be named "_alpm_XXX" for
instance (examples: _alpm_needbackup(), _alpm_runscriplet(), ...).
As of now, this scheme is only applied to most sensitive functions
(mainly the ones from util.c), which have generic names, and thus, which
are likely to be redefined in the frontend.
One can consider that the frontend should have the priority in function
names choice, and that it is up to the library to hide its symbols to
avoid conflicts with the frontend ones.
Finally, functions defined and used inside a single file should be
defined as "static".
Several structures and functions have been renamed compared to pacman 2.9 code.
This was done at first for the sake of naming scheme consistency, and then
primarily because of potential namespace conflicts between library and frontend
spaces. Indeed, it is not possible to have two different functions with the
same name declared in both spaces. To avoid such conflicts, internal function
names have been prepended with "_alpm_".
In a general manner, public library functions are named "alpm_<type>_<action>"
(examples: alpm_trans_commit(), alpm_lib_release(), alpm_pkg_getinfo(), ...).
Internal (and thus private) functions should be named "_alpm_XXX" for instance
(examples: _alpm_needbackup(), _alpm_runscriplet(), ...). Functions defined and
used inside a single file should be defined as "static".
NOTE: The below descriptions may be severely outdated. Yes it needs updating,
but it may be better done by doxygen comments and generated documentation.
[HANDLE] (see handle.c) [HANDLE] (see handle.c)