1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
|
[[meta copyright="Copyright © 2007 Free Software Foundation, Inc."]]
[[meta license="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled
[[GNU_Free_Documentation_License|/fdl]]."]]
## Mission
"To enable the GNU System to install packages of any format like rpm, deb,
ebuild... so that GNU System will be able to use softwares packaged by projects like Debian and Gentoo"
## Features
Basically all package management schemes follow similar approach, it will have a single binary archive containing the actual software and some metadata like packages it requires, what all it provides ... So when we install an rpm package this tool will help rpm tool to recognise the packages installed by stow and it will be stowed instead of the normal rpm way of installing in /usr.
There can be both aproaches
* Re-implement rpm, dpkg... to recognise stow as backend instead of its own data store. In that case we will have to re implement, apt-rpm, yum ...
* Implement a translator which reads stow and show it as an rpm data store for yum, deb data store for apt-get ...
One goal is obviously choice of packaging and hence availability of more packages. Also this gives maintainers a chioce to continue builing packages for GNU in the format they are already familiar with. The second goal is to demonstrate the flexibility GNU offers in implementing functionality in filesystems (open/read/write interface).
## Why?
* The GNU Hurd provides a lot of advanced features and functionalities. We aim to exploit those features.
* Combining translators with UnionFS gives a very exciting package manager.
* We could use the good features of existing packaging systems like deb, rpm, ebuilds, ports ... plus unionfs and hurd translator is a compelling compination.
With the increased flexibility in implementing filesystems as per the requirements, we can implement the functionality similar to apt-get, emerge or yum... (dependency tracking, versions tracking...) in the filesystem itself.
## What?
* Have a basic filesystem based package manager
* Write translators to convert between GNU's packaging format and the existing one's like rpm, deb ...
## How?
* Installtion of a package is just drag the pacakage (be it a tgz, rpm, deb or an exe) and drop it to the package manager.
* apt-cache search vim --> ls -al /packages/meta/ |grep vim
* apt-get install vim --> install vim
Just a sample script.
$ cd /packages/meta/vim/current/depends
$ for i in `ls *`
$ do
$ if [ -f /packages/binary/$i ]
$ then
$ echo "$i is installed"
$ else
$ install $i
$ fi
$ done
The same can be achieved using any of the languages or front ends or even manual copying.
If all the dependencies are there
$ cp -r /ftp/ftp.gnu.org/packages/binary/vim/7.0 /packages/binary/vim/7.0
## Implementation Details
Lets take the example of rpm, it is simply a cpio archive with software and
meta data as its contents. Just extract it to stow directory with a name
package-version. When apt-get or yum asks for information about already
installed packages read the stow tree and return back the requested data.
Same case for ebuild. We can provide these details to any packaging system
in the way it wants using a translator. So support for a new format is
just writing the new translator.
## Initial idea
A bit complex than the earlier scheme but it is more exciting and we can look at this schem seriously once we have the simple scheme working.
All packages are installed at
`/packages/binary/<packagename>/<packageversion>`.
For eaxmple vim 6.4 version can be installed from source like
# cd vim64
# ./configure --prefix=/packages/binary/vim/6.4
# make
# make install
Now if you have another vim version, say 7.0 then just follow the steps
# cd /packages/source/vim
# CP /<pathtovimtarball>/vim-7.0.tar.bz2
# tar -jxvf vim-7.0.tar.bz2
# mv vim70 7.0
# ./configure --prefix=/packages/binary/vim/7.0
# make
# make install
You have 2 versions of vim and how can you sepcify which one is the current version? You can symlink the current version to select the version you would like to see as default
# ln -s /packages/binary/vim/7.0 /packages/vim/current
## Metadata: /packages/meta
Dependency information is stored as a symbolic link to the required packages in a subdirectory called depends.
## Requirement
We will require unionfs support if we chose to go through path 2 (which is what I like because we can really show off with translators.)
* Developing status - planning
* Near term goal - implement stow backend for dpkg
* High priority task - make unionfs work on boot. Mail from AMS to gnu-system-discuss on problem statement <http://www.mail-archive.com/gnu-system-discuss@gnu.org/msg00198.html>
## Developer Guidelines.
* GNU coding standards <http://www.gnu.org/prep/standards/>
## FAQ - Frequently asked questions
1. How can I join this project?
OK. I will give you steps.
i. Install a GNU System by folowing [[these_instructions|setup]]
ii. Read about GNU Design <http://www.gnu.org/software/hurd/hurd-paper.html>
iii. Read about translators <http://www.debian.org/ports/hurd/hurd-doc-translator>
iv. Try out these cool [[translator_examples|translator/examples]]
v. Add your name below and give a shout in the list.
## Comments??
Add your comments here
## Interesting?
To join the project just list your name below.
1. PraveenA
2. IsaacPraveen
3. VikramVincent
4. MaheshM
|
