mirror of
git://slackware.nl/current.git
synced 2025-01-20 22:26:48 +01:00
66 lines
2.6 KiB
Text
66 lines
2.6 KiB
Text
|
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).
|
||
|
|
|