-
Notifications
You must be signed in to change notification settings - Fork 1
wu/npkgs
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
I work on many machines running several unix-like operating systems, and I want a consistent set of tools. This project contains a set of build scripts to build all my favorite unix tools (gnu ls, wget, curl, screen, git, subversion, perl, apache, etc)., with all my favorite options (e.g. 256 color terminal support) compiled so they work well together (e.g. apache mod_svn and git-svn). The goal of this project is to create a simple ports-tree like system that works on any unix-like operating system. At the moment I am testing heavily on OS X, Open Solaris, and Solaris 10. There are some amazing package management systems out there for a number of operating systems. I chose to do a number of things different. First, the assumption is that you are not building or installing these packages as root. Some of the prerequs may require root, but the number of external dependencies is kept as low as possible. This minimized the amount of customization that has to be done on each machine. Second, you will choose a prefix where you want the packages installed (your PREFIX). You could choose /usr/local, or you could just as easily choose /foo. Once you make up your mind, you will need to add /foo/bin and /foo/sbin to your PATH. Third, every package is installed into it's own version-specific directory. That's right, nothing gets installed directly into PREFIX/bin. Instead foo-1.0 will be installed into PREFIX/root/foo-1.0. This makes it very natural to have multiple versions of any package installed at the same time. A symlink will be created at PREFIX/root/foo to point to the one you want selected by default. PREFIX/ root/ foo-1.0 foo-1.2 foo-2.0 foo => foo-1.2 Then, all files in the directory tree selected by the 'foo' symlink will be overlayed back into PREFIX. For example, the file: PREFIX/foo/bin/foo.pl would get symlinked back to simply: PREFIX/bin/foo.pl This allows you to simply have PREFIX/bin in your path without needing to have the bin directory of every package you have installed. Otoh, it also gives you the flexibility to select a different version of a package if you prefer. For example, if you wanted to use the foo-2.0 version of foo.pl, you could simply set your path up like so: export PATH="$PREFIX/root/foo-2.0/bin:$PREFIX/bin:$PATH" This works great for testing out new packages without having to remove the old ones. It also means that you can instantly look at any file in $PREFIX and know exactly what package it came from (where does the symlink point?). This is especially good if you tend to do all your compiling on a single machine and then replicate that directory out to your production machines. In such cases, you can can easily pick and choose which packages to install on which machines by simply not copying those package's directories. INSTALLING 1. clone the git project cd /home/me git clone git://github.com/wu/npkgs.git 2. set up some environment variables export NPKG_PREFIX="/usr/foo" export NPKG_PATH="/home/me/npkgs" export PATH="/usr/foo/bin:/usr/foo/sbin:$PATH" 3. set up any custom config for your host or O/S (see the examples) $NPKG_PATH/common/os/MyOS/default.sh $NPKG_PATH/common/os/MyOS/version.sh $NPKG_PATH/common/host/shorthostname.sh 4. install c compiler(s) on your system - os x - install developer tools - install gcc - solaris 10 - install the sun compiler - install gcc from sunfreeware.com - required for a few packages - opensolaris - pfexec pkg install SUNWgcc sunstudio - install the devel/cbe port - this should be done with your own account, not root - pfexec mkdir -p /opt/dtbld/packages - pfexec chown myuser /opt/dtbld/packages - cd devel/cbe; ./cbe-1.7.0-rc1.x86.sh 5. link the npkgs script into your path The npkgs script lives in the root of the the npkgs project ($NPKG_PATH). To begin using it, symlink it into your PATH. For example if your NPKG_PREFIX is /usr/local: ln -s /usr/local/npkg/npkgs /usr/local/bin/ 6. install packages Use the npkgs script to install packages with dependency tracking, create symlinks, remove dead links. For example, to install git with all prereqs: npkgs install git You can also manually install a package by simply executing the shell script. For example: cd $NPKG_PATH/devel/git ./git.sh The package source will be downloaded and expanded into a work/ subdirectory, from where it will be configured/build/installed. The package will be be installed in $NPKG_PATH/root/git-version and then all files in that path will immediately be symlinked back into $NPKG_PATH. 7. uninstalling Removing a package is a two-step process. First, delete the installed package(s) from $NPKG_PREFIX/root, e.g.: rm -rf $NPKG_PREFIX/root/git-1.6.5.3 Second, remove any symlinks that pointed to this package, i.e. the dead symlinks: find $NPKG_PREFIX -type l ! -xtype f ! -xtype d -ls -exec rm {} \; SOLARIS AND OPENSOLARIS You may need to adjust your library paths. LD_RUN_PATH is now getting set properly, so everything may work just fine without having to create your own private ld.config file. The information is here in case you need it. Run 'crle' without any arguments to determine the current library paths, and then add $NPKG_PREFIX. There is no need to do this as root. export NPKG_PREFIX=/usr/local crle -c $NPKG_PREFIX/ld.config -l /lib:/usr/lib:$NPKG_PREFIX/lib -i /lib -i /usr/lib -i $NPKG_PREFIX/lib The above provides the safest way to run npkg since it takes your system library paths ahead of the npkg library paths. Some ports might not compile properly if you do this since the system libraries might not be new enought to satisfy some of the npkg dependencies. The recommended solution is therefore to list the npkg libraries first: crle -c $NPKG_PREFIX/ld.config -l $NPKG_PREFIX/lib:/lib:/usr/lib -i $NPKG_PREFIX/lib -i /lib -i /usr/lib After doing this you must export the LD_CONFIG environment variable to be the path of the ld.config file you specified. export LD_CONFIG=$NPKG_PREFIX/ld.config You'll need to repeat this process every time you install a new dynamic library. This will eventually be automated.
About
Not a PacKaGing System, automated cross-platform build scripts
Resources
Stars
Watchers
Forks
Releases
No releases published
Packages 0
No packages published