Re: Status

[Alfred M. Szmidt]

Hi!

Sorry for the late response.  This is what Pravi posted on
http://hurd.in/bin/view/Hurd/UniversalPackageManager, my comments are
the lines that are not quoted.  Other than that, it is keept verbatim.

I still do not fully understand how this is different from what stowfs
does in its current stage.

| * Why?
|
|  o The GNU Hurd provides a lot of advanced features and
|    functionalities. We aim to exploit those features.

|  o Combining translators with UnionFS gives a very exciting package
|    manager.

|  o 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.

We can't.  apt-get, emerge, and yum are interactive processes, a
file-system requires a non-interactive processes since it doesn't have
any communication with the terminal and keyboard.  If something goes
wrong, you want it to fail as cleanly as possible, the more `magic'
you add, the worse things can fail.

| * What?

|  o Have a basic filesystem based package manager

FYI, this is almost done, stowfs.

|  o Write translators to convert between GNU's packaging format and
|    the existing one's like rpm, deb ...
 
I think this is a bad idea, we don't gain anything from this.  And it
takes considerate amount of time to write even a bad converter.  alien
tries to achive the same task, but it is really bad for anything other
than really basic usage.  Infact, it is simpler to just extract the
content of the binary package, and use that directly without having
any kind of converter that tries to map over the dependencies,
post/pre installation scripts, etc.

| * How?

|  o 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.
|  o apt-cache search vim --> ls -al /packages/meta/ |grep vim

Isn't this much like the Free Software Directory?  Wouldn't it be
better to provide a single big file that one can search through (if
one is off-line)?

|  o apt-get install vim --> install vim

`install' is already a taken command, it is used by GNU make to copy
programs to their corresponding destination; a better name would be
pkginstall. Do you mean that this pkginstall program is a front end
over `ln -s /stow/emacs /packages/emacs-21.4'?  That is the goal to
have, the command could ask the user if he wants to download any
dependencies, just like apt-get and similar programs.

| 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.

See above.

| If all the dependencies are there

| $ cp -r /ftp/ftp.gnu.org/packages/binary/vim/7.0 /packages/binary/vim/7.0 

How does one know if all the dependencies are there?  Why is this
different from `pkginstall' (what you call `install')?  Why is this
difference needed?

| * Implementation Details 

| All packages are installed at 

| /packages/binary/<packagename>/<packageversion>

This was discussed quite a bit, and we kinda decided to stick to /stow
for stowfs, and /packages/FOO (as the default places, the system
administrator can use anything he fancies) for now, we can change this
later.  I do not understand why the subdirectories are needed though,
but that isn't important, the ultimate goal is that one directory
--where this directory resides is not important--contains the binary
package, which you make a symbolic link to /stow.

| For eaxmple vim 6.4 version can be installed from source like

| # cd vim64
| # ./configure --prefix=/packages/binary/vim/6.4
| # make
| # make install

Small nitpick, it is better to use `--prefix=' and then do `make
install DESTDIR=/place', since then when you install site specific
files (like for emacs), you won't end up installing them in the
directory of the actual program, and mix things up.

| 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

Note: The directory shouldn't matter.  The system administrator should
be able to pick any directory he or she wishes to use, and then just
symlink it into /stow.

| 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

What is wrong with just using /stow (or whatever)?  It is much simpler
to implement, and manage.  And on top of it all, it works right now.
Only the booting problem persists.  Would you like to try and fix
this?

| * Metadata: /packages/meta

| Dependency information is stored as a symbolic link to the required
| packages in a subdirectory called depends.

How the current system dependencies are presented is up for debate.  I
think that each binary package should have a SUMMARY/ directory, that
contains the dependencies it requires.  Then this data is presented in
a dynamic file in /stow/SUMMARY/dependencies or similar, which
apt-get/pkginstall/emerge/... can use to figure out what is missing,
and what is not.


Happy hacking, and I'm really sorry for the late reply.