To do list
----------

Likely to be done:
==================

This list represents changes that I am likely to implement myself:

Thinking about it:
==================

1.  Modify slacktrack to do a couple of scans of the filesystem prior to
    launching the build script.  
    It'd compare the scans and add any differences to an exclude list -- since
    any such differences were not generated by the build script, thus should not 
    be in the package.
    The purpose of this is to reduce the possibility of non package material making
    its way into the final .tgz.
    *However*, there's nothing to say that some arbitary cron job won't launch and
    modify the filesystem anyway -- so this sort of feature would only lead to
    confusion in the long run.

2.  Allow addition of exclude/additional scan dirs without having to replace
    the existing list.
    Suggested by: Eduard Rozenberg

3.  Compare contents of new package and warn about any overlapping files.
    This is harder to do that it sounds because the user may not be removing
    the previous package (although it's suggested that you do) because it's
    an integral system library or binary and they simply want to upgrade
    it and produce a package.  This would always talk about overlap.
    We could get the 'base package name' of the supplied package
    and then remove it from any found ovelap results, but it seems
    a bit slow.

Unlikely to be done:
====================

This list represents future additions that (for one reason or another) I am
unlikely to implement.  However, feel free to submit a patch (but ask me first -
I don't like receiving unsolicited attachments!).

2.  Add an option to rename/move .conf files to conf.new
    Suggested by Geoffrey Sanders, based on an option protopkg supports.
 
    [..]
    > altertrack to (during it's file scan of new files for the package) to
    > move any newly created .conf (or any other type of config files) to a
    > *.new extension. Don't know how much work this would be...but thought
    > that it might be nice to add for those of us who may forget to 'backup'
    > any config's that may get stepped on.
    [..]

    I must admit that I'm not overly keen on this idea - it sounds too much
    like checkinstall -- add a feature that mainly works but breaks when you
    least expect it. 

    Just moving the .conf to .conf.new is okay in theory but it may:
    a) catch people out who rely on the feature but where the config
       file isn't called '*.conf'

    b) if it updates the doinst.sh script, the shell script which changes
       the file name may need to be before or after the symlink creation
       code (if there is any).