>But I'd rather tell it to use "/usr/bin/gzip -9" manually than let it
>futz around with figuring out which gzip to use. ...
And are you also willing to handle the E-mail from each and every new
Amanda user who gets it wrong? :-)
>1. It means I have to keep a locally-compiled version on each of my
>machines ...
Do you mean a locally compiled version of Amanda? If so, that's the
strongly recommended approach anyway. Amanda and pre-compiled are
(in general) not a good combination.
Although the reason that's so is because of all the compiled in values
(i.e. this is a circular problem). Feel free to patch Amanda to support
what you want in amanda.conf at run time and post the changes.
>2. If I wish to use different compression programs for different
>filesystems or configuration sets, I can't without using multiple
>installations of amanda, which is a real PITA.
Also not true (you can use wrappers around the compression program and
let them decide, for instance), but I agree it's still a PITA.
>> Look at all the incredible amount of effort it has to put in to deal
>> with "program dump".
>
>That's a different case. "dump" and "tar" are not so substantially
>similar as gzip and bzip2, nor do they act as simple pieces of a pipe
>as gzip and bzip2 do.
Actually, I wasn't talking about dump vs. gnutar. I was talking about
the umpteen ways just "dump" has to be be handled depending on OS type,
FS type, day of the week, ad infinitum. And my point was that Amanda
deals with all that for you.
You're correct that things are (might be -- I don't really know anything
about bzip2) simpler if we're talking about gzip and bzip2. But what
about some other mythical compression program that looks and acts totally
different from them and needs a lot of extra support?
Be that as it may ...
>> In the long term, there is a FILTER-API proposal ...
>
>Where can I find information about this?
I'm not sure. I thought it would be in the docs subdirectory, but don't
see it. The next place I'd look is the amanda-hackers E-mail archive.
And just so we're clear, I'm not opposed to any of this. I'm just
rambling when I really should be coding :-).
>John Goerzen
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
