blob: 28c22b04ab3a69d87dfcb61e15ec53965be9745c (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
|
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).
|
