Things to think about for the next release of graft --------------------------------------------------- In no specific order ... ########################################################################### - still more perl cleanups. I'm sure there's more abstraction that can be achieved. The install() and uninstall() routines are just too big. - we can coerce all the options into a hash, eg $graftOptions{veryVerbose} - separate out option parsing and arg parsing into separate routines - for each directory, process all files and subdirs in one pass and the simply symlink those files that passed the processing and descend into those dirs that passed the processing. ########################################################################### Create a test harness so that make test can be used. Useful for regresion testing and bug fixing. Also think about using the Test::Simple and Test::More test harnesses which ship with Perl. ########################################################################### Would using Getopt::Long be of any use? ########################################################################### When an error is flagged, do we want to spit out the whole usage information? How about a briefUsage() and verboseUsage() along with a -h flag for help? ########################################################################### - have another good look at Norbert Preining's .graft-remap patch. Do we really want to remap directories? Norbert's idea is to have a .graft-remap file that would allow you to remap a directory. For example, in the directory /pkgs/package-1.2.3.4/doc/ the .graft-remap file would contain doc/package-1.2.3.4 This would mean that for the file /pkgs/package-1.2.3.4/doc/xyz.html the grafted symlink would appear in /pkgs/doc/package-1.2.3.4/xyz.html -> /pkgs/package-1.2.3.4/doc/xyz.html instead of the traditional graft location of /pkgs/doc/xyz.html -> /pkgs/package-1.2.3.4/doc/xyz.html This means that we'd need to honour the .graft-remap file when deleting and pruning as well as installing. Should we honour and dishonour the file when deleting and pruning - ie do we want to ensure that a graft of a package before .graft-remap file existed followed by another graft after the .graft-remap file was created is correctly cleaned? Currently I'm thinking this is too much work with too much checking to do. Norbert's problem can be solved with a little extra grafting: mkdir -p /pkgs/doc/package-1.2.3.4 graft -i -t /pkgs/doc/package-1.2.3.4 package-1.2.3.4/doc ########################################################################### - While we're on the subject of remapping, investigate a file remapping feature - ie graft files with a different name. Could be useful for avoiding conflicts and for forcing file name prefixes for preinstalled packages. Eg /pkgs/bin/gmake -> /pkgs/gmake-3.5.6/bin/make Will require double processing for deletion and pruning ########################################################################### - Peter also requested a partially verbose -N flag that only outputs the SYMLINK and MKDIR actions (and supposedly the RMDIR, UNLINK and RENAME actions when deleteing). I don't think this is a good idea. If you want to trim output, pipe it through grep. If it's something you require consistently, write a shellscript wrapper around graft. mygraft $@ | egrep -v -i "smylink|mkdir|unlink|rename|rmdir" I'll gladly accept contributions for graft wrappers. This could be a good use of the file remapping feature (which does not yet exist, see above). /pkgs/bin/graft -> /pkgs/graft-wrapper-1.1/bin/graftwrapper /pkgs/bin/graft_exec -> /pkgs/graft-2.5/bin/graft The graft wrapper calls /pkgs/bin/graft_exec. ########################################################################### - Alan Bailey asked for the following: "Have you thought about supporting multiple levels of grafting? stuff grafted from A/packages/ to A/[bin|etc|lib] stuff grafted from B/packages/ to B/[bin|etc|lib] Then I want to graft stuff from A and B into a further directory C. I infer that I could do this with some complex graft -t statements. However, I'm just wondering if you had thought about this as a feature that can be configured in the Makefile. Where I work we have a complex directory tree spanning many different architectures and also programs common to all architectures (like perl scripts)." On the surface this sounds like a good idea but it could lead to lots more work than you might think. You'll need to be careful with conflict resolution for files with the same name. There's a high probability of lots of duplicate file names A/bin/file1 B/bin/file1 A/bin/file2 B/bin/file2 A/bin/file3 B/bin/file3 ... ... Which file takes precedence? Are they really identical? What happens when you upgrade a program for a specific architecture and/or OS release that is not backward compatible for the other architectures and/or OS releases? My feeling is that it is better to have the duplication of files to avoid these problems. I've also had to support multiple architectures and mutliple OS releases for the same architectures and having completely separate trees was an advantage in the long term - especially for legacy systems. There was almost never any confusion as PATH and MANPATH variables were set to search the correct arch-os directories which allowed the separation to work well. ########################################################################### Provide RPMS for Graft! Sounds weird, I know. But it might make it easier for people to install graft and just use it rather than have to make all sorts of location decisions for themselves. Also, by providing a spec file, people can make a simple RPM for themselves which will make upgrading graft easier. Could even be useful for distrubutors :) ###########################################################################