graft
Graft provides a mechanism for managing multiple packages under a single directory hierarchy. It was inspired by both Depot (from Carnegie Mellon University) and Stow (by Bob Glickstein). Packages are installed in self-contained directory trees and symbolic links from a common area are made to the package files.
| Tags | Software Development Build Tools Archiving Packaging Systems Administration Software Distribution Tools |
|---|---|
| Licenses | GPL |
| Operating Systems | POSIX |
| Implementation | Perl |
Recent releases
- 25 Feb 2002 21:39
Release Notes: The previous version would carry the contents of a .graft-include file into other directories. This resulted in these subsequent directories being ignored. This version fixes that bug. A NEVERGRAFT Makefile directive has been added so that files and/or directories such as CVS, RCS, etc. are never grafted. The list is specified in the Makefile and controlled by the -C command line option.
- 08 Sep 2000 01:14
Release Notes: An include mechanism is now provided to exclusively graft files and/or directories.
Recent comments
Re: Also consider encap
> Also don't forget Encap which I think is
> the oldest of them. I can't compare them
> since it's been a while. But for Linux
> users, the main difference between these
> and rpm is that you can keep multiple
> installs of the same package in at once
> ...
I haven't forgotten Encap. See the graft documentation. (graft.html) I wasn't aware of Encap when I started graft. I have since had a look at encap and incorporated some of its features into graft. Once again, see graft.html.
Graft too allows you to have multiple installations of the same package. That was the primary reason for developing it.
Also consider encap
Also don't forget Encap (http://freshmeat.net/projects/epkg) which I think is the oldest of them. I can't compare them since it's been a while. But for Linux users, the main difference between these and rpm is that you can keep multiple installs of the same package in at once (you do ls -la filename instead of rpm -f filename to find out which package is which). The main disadvantage is, you have to leave old packages installed or possibly break package dependancies (since other packages may have been built against old libraries). This leads to possibly large /usr/local (or whatever mount point it's in).
It would be interesting if these packages could read the SRPM spec files but build into it's directories (of course, most RPMs can't install into any directory) and did the autodependency checking that rpm is good for.
peter_r_samuel
16 Mar 2010 14:08
