[Filterproxy-devel] filterproxy upgrade

[Bob M. <mce...@dr...>]

I noticed your bug report to debian.  You should send such things to me too=
, as
this affects the whole package.

Having never received any Rewrite rules from anybody, I've been unsure if
anyone was writing any!  If you have some interesting rules, please consider
sharing them.  ;)

How about the following:
I could write a little script 'confmerge' that would take the user's old
configuration file and merge it with a new one.  The user's config file wou=
ld
take priority where there are conflicts.  This is simple *unless* you want =
to
use the rule updates that I write.

What would you suggest for merging Rewrite rules?  diffing of regular
expressions is hardly a straightforward matter.  In this release I've taken=
 the
really big rule (ADS) and used the m//x construct to put whitespace in it,
spread it over several lines, so looking at a diff of it could be useful, b=
ut
in general comparing regexes is very hard to do by eye.

So let's say for instance that you have modified the rules for the andover.=
net
set of sites (the long one that includes slashdot).  In this release I have=
 the
following rules:
    1_ANDOVER_ADLOG
    1_GREENDOT
    1_OSDN
    1_ANDOVER
If one of these is modified in the user's old config file, should 'confmerg=
e'
choose the user's old one?  Give the user a chance to edit the rule?  Choose
the new one?  Keep in mind that for most users, most of the rules in the new
release will have been modified by me, and they will have never seen the ru=
le
before.  Asking them to decide which one to keep is probably not reasonable.
I suppose it would be possible for every new release to keep a copy of the
previous release's config file for comparison (and could then automatically
detect if the rule was modified by the user since the last release).  But t=
his
would make non-incremental upgrades a bitch.

What about if the user has deleted one rule (say 1_ANDOVER_ADLOG) from a si=
te.
Should 'confmerge' add it back in?

Note your suggestion of separate conf files doesn't really fix this because
this issue of merging rules is non-trivial. =20
> filename.def is the default config file to be modified by dpkg only,
> filename.rul the rule filename for the users override file.
I don't really want to make a distinction between "my rules" and the user's
rules.  My rules are not in principle better than ones someone else would
write...  And it doesn't solve the diffing problem.

Please, how could I make this better...

Cheers,
-- Bob

Bob McElrath (rsm...@st...)=20
Univ. of Wisconsin at Madison, Department of Physics