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 choice to continue building 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 combination.

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?

  • Installation of a package is just drag the package (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 more complex than the earlier scheme but it is more exciting and we can look at this scheme seriously once we have the simple scheme working.

All packages are installed at /packages/binary/<packagename>/<packageversion>.

For example 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 specify 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.)

Developer Guidelines.

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

ii. Read about GNU Design: Towards a New Strategy of OS Design

iii. Read about translators http://www.debian.org/ports/hurd/hurd-doc-translator

iv. Try out these cool translator examples

v. Add your name below and give a shout in the list.

Comments??

Add your comments here

Interested?

To join the project just list your name below.

  1. PraveenA
  2. IsaacPraveen
  3. VikramVincent
  4. MaheshM
  5. Nidhin Raghavan
  6. Ajish.B
  7. Ambili.B
  8. Abhradip Mukherjee
  9. Ermenegildo Fiorito
  10. Oltion Doda
  11. Russell James