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@xxxxxxxxxxxxxxxx 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review