Hylafax Mailing List Archives
|
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
Re: Hylafax rpm issues
Disclaimer:
----------
I am only trying to build the RPM just the way Redhat does, so
that Redhat would consider including it in their distribution.
So far, I haven't contacted anybody from Redhat.
I am surprised by the amount of controversy my rpm created. Perhaps
I should emphasize once more my objective in building this RPM.
(1) I want hylafax to work out of the box with minimal effort
for the end user.
(2) I want Redhat to include hylafax in their distribution. So I
want to make it as Redhat compliant as possible.
I am a reasonable person and open to suggestions. There is no point
in getting into a fight for minor points.
Let me address some of the objections that were raised about
the RPM. Please consider each issue independently and
Skipping 'faxsetup' and 'faxaddmodem'
------------------------------------
This was probably the most controversial issue.
I didn't have much trouble with 'faxsetup'. But rpm postinstall script
already handles faxsetup's duties.
The recommendation that I made 'faxaddmodem' was based on my
frustration with it as an end user. I had to almost understand half of
the 'faxaddmodem' script to figure why it was hanging. I tried with 3
modems: a US Robotics Sportster, Cardinal MVPV34I, a Zoltrix modem. In
no case, could 'faxaddmodem' sniff all the parameters of the
modems. It is pointless to argue that their firmware is faulty and not
the script. Lot of potential hylafax users have these modems.
This was very frustrating because I could send and receive with a
simple package like efax using the same Cardinal modem. After I looked
at the config file it produced, I was wondering whether all the
trouble I had was worth it. It would have been simpler if I had
a template config file and tweaked one or two parameters to get
it working.
Perhaps my experience was unusual. Perhaps 'faxaddmodem' works
flawlessly for most people. On the other hand perhaps many
people gave up when it didn't work for them and never reported
in this mailing list. I know that I tried to make it work six
months ago. I just gave up and moved onto something else.
I don't understand why it is any easier to throw a question like
Getty Args [-h %l dx_%s]?
than editing the same line in config file. I bet most people don't
have any clue about what argument getty takes. At least they know that
if the config file was produced for Linux, they may not need to change
it.
Finally, it is not as if I removed the scripts 'faxsetup' and 'faxaddmodem'.
People can still use them to generate the config files for them.
Change of directories and names
-------------------------------
(a) /usr/local to /usr
This is by Redhat's convention. We are not going to
get Redhat to bundle any package with files in
/usr/local. Of all the issues that were raised
this is the only one I insist on. I am flexible
on every other issue.
(b) /var/spool/fax to /var/spool/hyla
I don't have a strong opinon on this. I thought of
changing it only because it was conflicting with
other packages like mgetty+sendfax. If there is
a strong opinion on keeping it the way it is,
I am willing to do so.
(c) xferstats to xferfaxstats
This is prompted by moving from /usr/local to /usr
IMO, even if it is kept in /usr/local, the name should
be changed to a more unique name. However, I don't
want to be perceived as "reactionary" or "arbitrary".
I am flexible and open to suggestions.
It is important to remember that hylafax has to peacefully coexist
with other programs. It is especially important in Linux becomes
it comes with lot of software bundled on it. The less intrusive
hylafax is, the more successful will it be.
Ramana