[Bug 188542] Review Request: hylafax

Sat Jul 5 00:49:17 UTC 2008

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: hylafax

https://bugzilla.redhat.com/show_bug.cgi?id=188542

------- Additional Comments From faxguy at howardsilvan.com  2008-07-04 20:49 EST -------
(In reply to comment #88)

I've made a change to %{_libdir}/libfax*

(In reply to comment #89)

This is a bug in the ghostscript package and not HylaFAX.  HylaFAX is extracting
the path from the 'gs -h' output.  HylaFAX's faxsetup will compensate for this
ghostscript bug later during setup and configuration.

(In reply to comment #90)

I've followed your fedora-devel discussion here:

http://fcp.surfsite.org/modules/newbb/viewtopic.php?topic_id=57663&forum=11&post_id=268715

There seems to be a resounding consensus with respect to the FHS matter and a
very undecided response to the naming matter.

Please allow me to restate my positions on these.

My positions are entirely based upon anticipation of user expectations,
minimizing support cases, and making everything as intuitive as possible.  In
fact, these concerns are the only reason for my creating this review request in
the first place: if there were a hylafax package in Fedora already I wouldn't
have bothered - there would have been no reason for this effort.

As HylaFAX is approaching it's 20th birthday and is almost certainly the
most-popular open-source fax application for UNIXes, it's silly that Fedora does
not have a hylafax package.

RedHat 5.2 *did* have hylafax-4.0pl2 (that's the SGI flavor, not from
hylafax.org).  RedHat apparently decided to drop the hylafax package due to
conflicts with the mgetty-sendfax package.

(That is interesting because the mgetty author created the conflict... as his
approach at the time was to write his own fax software instead of participate
with HylaFAX development.  And, in particular, he chose to use "sendfax" for one
of the commands... and thus created the conflict.  One could argue, and I would
agree, that "sendfax" is generic enough to be the presumptive way to send a fax
with a command.  Nevertheless, this seems to be the reason why hylafax was
tossed from RedHat 6.0.)

Again, I'm okay with calling the package hylafax+ instead of hylafax.  I think
that would be a mistake, though.  And I think having a "hylafax.org" and a
"hylafax+" but no "hylafax" (cutting the baby in half) would be an even worse
mistake.  Why?  Because all HylaFAX users, whether they use SGI's flavor,
hylafax.org's flavor, iFax's flavor, or HylaFAX+ flavor... they all call that
software "HylaFAX".  And they're all right, too.

If hylafax.org really wanted to submit a package request and maintain it, then I
would wholeheartedly acquiesce and say to put that in as a "hylafax" package
into Fedora.  I would never use it, myself, of course... but my whole reason for
creating this package review request in the first place has always been to see a
HylaFAX package in Fedora for other users.  You don't see me trying to bully-in
a hylafax+ package into Debian/Ubuntu for exactly this reason.

Both HylaFAXes at hylafax.org and Sourceforge (HylaFAX+) are so similar that
it's really inaccurate to describe their differences as a fork.  I don't think
there's an accurate label, but a certain well-known open-source philosopher once
called it a "pseudo-fork" when I brought up this concept to him.  He said that
this case is very similar to what happens when a distribution packager adds a
few patches here and there to suit the distribution schema or to address bugs or
even enhancements that appealed to the packager.  He indicated that use and
functionality were the criterion by which a fork was to be defined... and not so
much on code specifics.  In other words, we could create a software package
called "hello_world" that was coded in shell this way:

echo "Hello world!"

And then someone came along and rewrote hello_world in this way:

printf "Hello world!\n"

Are they forks?  Maybe there is a reason to prefer one over the other, but
they're functionally the same, and there's absolutely no sane reason to try have
both of them.  Pick one or the other.  If a time comes that one is preferred
over the other, then simply change, and keep on calling it hello_world.

I realize that's an over-simplified example, but I'm trying to illustrate my
perspective here... and what I believe is the general user perspective.

Users are going to want to do: 'yum install hylafax'.  For users who already
know that HylaFAX on Fedora is called "hylafax+" or "hylafax.org" then doing
'yum install hylafax+' may be beneficial, but it will create a support matter
and a point of confusion for every first-time installer.

There seems to be some suspicion on your part, Jason, that I have some nefarious
intention "in (what seems to [you] to be) an attempt to gain legitimacy".  I
think that you've entirely misunderstood what I've done.

I coded at hylafax.org for several years.  There was an occasional flare-up with
respect to opinions on aesthetics of the coding being committed to the
repository, and an occasional flare-up with respect to design approaches, but as
ugly as those sometimes got the code changes were almost always followed, and
they weren't the reason why I moved my coding to Sourceforge.

In fact, I set up the Sourceforge site as a download location for HylaFAX...
specifically pre-release versions of HylaFAX.  You see, I always had been
frustrated with the slow release schedule at hylafax.org.  Users were regularly
and frequently (multiple times per week) requesting that I send them pre-release
tarballs or pre-release RPMs.  It became very frustrating to answer mailing-list
questions over and over again for weeks and months about bugs that were "fixed
in the next release".  So I finally made the decision to just set up a site
where users could just download those pre-releases for themselves.

The end-result of this action was a complete rejection by other hylafax.org
developers (all of whom were/are employed by iFax).  They insisted that
references inside of the tarball (code, manpages, and text files) should have no
reference to hylafax.org or "The HylaFAX Development Team".

The only way that I could sanely accommodate that was to set up a separate code
repository.  Then I embarked upon a number of months where I was trying to
maintain two code repositories (and that never works: it's a real pain, as it
had been when those same hylafax.org developers asked me to code in a 4.2 CVS
branch while expecting me to also maintain the old 4.1 branch that eventually
did nothing for open-source HylaFAX users and never had another release).

So basically what happened was that iFax made it increasingly impossible for the
largest code contributor, me, to continue to operate at hylafax.org.  And, yet,
they were as eager as always to absorb the developments I would make at the
Sourceforge site.

So we now have a situation, then, where there are two versions of HylaFAX that
are basically following the same development path... one behind the other. 
There are some differences, but they're nominal for most users, and
functionality and use are identical (the differences follow the hello_world
example quite literally although not as simplistically).

The HylaFAX+ name came about because some users were quite emphatic that they
needed some distintion between "the Souceforge HylaFAX development project" and
hylafax.org.  In retrospect, I now tend to believe that those clamors were
coming from hylafax.org enthusiasts whose intentions were really to strip
legitimacy from my efforts.

I hope that clarifies my intentions.  If they continue to seem nefarious to you,
then I sincerely apologize.  I truly believe that my actions and intentions have
always been done in good faith and with the users' interests in mind.

So, again, I'm happy to change the name of the package to "hylafax+" if that's
what's really the hold-up here.  I disagree with it, but I'm willing to do it
if, indeed, that's the hold-up.

Unfortunately, I don't think that using "Provides: hylafax" helps any.  In an
'rpm -Uvh' procedure (upgrade) this still happens (in extreme multiplicity):

file /var/spool/hylafax/etc/dialrules from install of hylafax+-5.2.5-1.fc8.i386
conflicts with file from package hylafax-5.2.0-1.fc8.i386

Maybe someone better with spec files can tell me what I didn't do right.  But
this kind of thing is *exactly* what must be avoided.  Users need to be able to
transition between hylafax.org and HylaFAX+ (and Fedora) RPMs without these
kinds of headaches.

And as for the FHS matter...

I hope that you can understand that I cannot change how the upstream package is
installed or works in such a dramatic way as it would be to move "bin", "etc",
and "config" elsewhere.  The resulting support issues would simply be too great.

Now, we may be able to get away with symlinking as the fedora-devel tread
suggests, but it would be something that would be unique to the Fedora
package... unless it were so interchangeable that it would work for all other
platforms (e.g. Mac OS, Solaris, BSD, AIX, IRIX, SCO, etc.) too.  And even then,
I would be reluctant to do it.

You see, having it all right there allows the hfaxd client (much like an ftp
client) in an administrative mode to get in to the configuration files in those
directories (yes, "bin" contains executable scripts which are largely considered
configurable) and make adjustments that way.  So it could be quite useful to
have all of those things there.  Certainly it's much more convenient to have
them there.

Thus, it is my perspective that those directories do very much belong under
"var", and there really is no more-appropriate place to put them other than
"spool"... in my estimation.

Maybe that concept is stretching it a bit - nobody probably uses bin, etc, and
config files in that way.  But it's a design feature that I don't feel
necessarily warrants change.

However, if this is the only thing holding up getting this package into Fedora,
and if we can make adjustments that prove to be transparent to the end-users,
then I can work with that (I'll need some detailed explanations of what to do)
in a Fedora-specific way as I've stated above.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.