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. _______________________________________________ gnu-system-discuss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-system-discuss
