Hide Forgot
Description of problem: Your package, hylafax+-5.5.2-7 provides and obsoletes existing other hylafax RPM installations out there, which are not hylafax+. This is inacceptable to me. I want to remind, that hylafax+ is just a fork of hylafax and both projects are actually still active and alive. What you are doing in the package right would be like postfix killing existing sendmail installations. Finally, somebody could package the other hylafax fork (the original) also for the inclusion in Fedora and EPEL and I think you heavily would dislike it, if somebody then puts in an obsoletes/provides for hylafax+, just because the other hylafax fork is already on version 6.0.x ;-) Please remove the Obsoletes:/Provides: tags from at least the EPEL packages and push updated packages to the repository. Version-Release number of selected component (if applicable): hylafax+-5.5.2-7 How reproducible: Everytime, see above and below. Actual results: hylafax+ obsoletes and provides hylafax. Expected results: hylafax+ should neither obsolete nor provide hylafax.
And please do not argue, that hylafax+ is completely superior or that the migration from hylafax to hylafax+ is seamless - which is definately not the case if you use hylafax version 6.0.x already.
Hi Robert. I believe that the Provides and Obsoletes parameters are doing exactly what they are intended to do and are consistent with the Fedora Packaging Guidelines as well as community input provided during the package vetting process. Fedora documentation is extremely clear that care should be taken whenever installing packages from outside the Fedora repositories. In the case where a third-party package is installed and desired to not be altered by Fedora updates the administrator should consider using the "exclude" option in yum.conf to prevent the package from being replaced by a package in the Fedora repositories. In the event that the system administrator does not do such configuration to preserve the specific package installation this is interpreted to mean that the administrator desires the package to be updated by Fedora system updates should updates to the package be made available. The packaging guidelines state that Provides and Obsoletes should be used when a package "is a compatible enough replacement to an existing package (where 'enough' means that it includes only changes of magnitude that are commonly found in version upgrade changes)".... "If a package supersedes/replaces an existing package without being a compatible enough replacement as defined in above, use only the Obsoletes from above." http://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages I believe that HylaFAX+ 5.5.2 is compatible-enough with any previous HylaFAX release (including those from hylafax.org) to warrant both Provides and Obsoletes. Your comment #1 expresses the claim that this is not the case, and I would ask that you explain which elements are incompatible. The sendmail vs. postfix example is innapplicable to this case for several reasons among which is that sendmail and postfix were permitted to operate in alternatives whereas hylafax vs. mgetty-sendfax were not (and one would assume that the same would be true for any hylafax.org vs hylafax+ conflict). (See bug #188542.) An example that is much more-similar would be that of eggdrop's own fork selection. As for the assertions about originality and fork superiority I respectfully choose to disagree with you. Your raising of those points while asking to not discuss them is confusing. If you would like to discuss them, then I will do so. If you would not like to discuss them then why mention them?
Another good example would be that of openoffice vs. libreoffice. I note the Provides in the libreoffice SPEC file.
Actually openoffice vs. libreoffice is different, because you really can use libreoffice as a drop-in replacement/upgrade for openoffice. And even nothing breaks, if you do so. I can't confirm the same for hylafax to hylafax+, just give it a simple try yourself?! /etc/cron.daily/hylafax of hylafax can be disabled via /etc/sysconfig/hylafax, while this can't be done on hylafax+ except by changing or removing the cron. I can not see how I would bind hylafax+'s hfaxd to listen only on 127.0.0.1 at all, because of lacking /etc/sysconfig/hylafax or equivalent. Same would apply for maybe other less common used daemon arguments. Why does "%config(noreplace) %{faxspool}/etc/xferfaxlog" exist that way? I am maybe wrong, but xferfaxlog feels for ages like a log file, but never like a configuration file, thus it should be neither %config nor use "/etc" at all. Shouldn't /var/spool/hylafax/FIFO be %ghost'ed instead of not packaged any more like it is case now? Because it IMHO needs to be removed, if you are uninstalling hylafax+. Hylafax was faster than hylafax+ implementing e.g. IPv6 support into a stable release. Additionally Hylafax is backed by a company, not only by community. Both of the above given examples are a good reason for choosing hylafax over hylafax+ - especially in EPEL. This of course might be different for Fedora. The other stuff which makes the switch from HylaFax to HylaFax+ painful seems to be changed paths to match the LSB a bit more than before - which is okay. Additionally your packaging is even less flexible right now than that one by hylafax. With hylafax, I do not have to install the server on a box that shall only act as a hylafax client. That avoids the installation of various packages that are only needed for the server components. Will we at least get the packaging matters (hylafax cron, arguments to hfaxd, xferfaxlog in etc, not packaged FIFO and missing separation into client and server and "common" if needed) get solved? I am even happy to support this by patching and testing - finally the more flexible packaging would also make me re-evaluating the hylafax vs. hylafax+ decision for our customers at work. A more flexible packaging however is the absolute must therefore. Otherwise we will maybe try to get the original hylafax at least into Fedora EPEL.
Hi Robert, I do drop-in HylaFAX+ replacements for hylafax.org releases all of the time. I am willing to concede that there may be something that I don't know, but it works for me. So if you know something that I don't I'm happy to work at that. Based on this last reply from you the differences appear to be mostly packaging releated. I will add /etc/sysconfig/hylafax usage to the HylaFAX+ installation. That will resolve your concerns about disabling faxcron and hfaxd binding. xferfaxlog is marked %config because we don't want it removed with an uninstallation. Is there a preferred way to do that other than with %config? The location of xferfaxlog has always been in the HylaFAX spool etc directory. I didn't make it that way, so I cannot explain why it is there instead of the log directory. Moving it to the log directory is certainly possible, but doing so tampers with decades of exposure in the etc directory... so we'd need to do that VERY carefully to prevent problems. I will %ghost the faxq FIFO. However, all of the modem FIFOs will need to be removed by hand unless there is a scripted way that FIFO* could be removed during uninstallation. With respect to IPv6 support, that made it into hylafax.org 6.0.0 release on Apr 24 2009, but there were serious portability bugs with it until 6.0.4 which occurred on Dec 29 2009. HylaFAX+ IPv6 support appeared in v5.3.0 on Oct 25 2009. Given general FOSS spirit, I would think that "community support" should not carry any bias as you've expressed. However, HylaFAX+ is supported by numerous businesses - most of whom do not want their support publicized - but one notable one I can mention is Mainpine (modem manufacturer). I can break HylaFAX+ up into multiple packages if you truly feel that's better. (I'm uncertain, however, as to why anyone would want a HylaFAX server without HylaFAX clients available as they are useful tools.) So you want to see hylafax+-common, hylafax+-server, and hylafax+-clients?
hylafax+-5.5.3-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/hylafax+-5.5.3-1.fc17
hylafax+-5.5.3-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/hylafax+-5.5.3-1.fc18
hylafax+-5.5.3-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/hylafax+-5.5.3-1.el5
hylafax+-5.5.3-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/hylafax+-5.5.3-1.el6
Package hylafax+-5.5.3-1.el5: * should fix your issue, * was pushed to the Fedora EPEL 5 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing hylafax+-5.5.3-1.el5' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-0453/hylafax+-5.5.3-1.el5 then log in and leave karma (feedback).
hylafax+-5.5.3-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
hylafax+-5.5.3-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
hylafax+-5.5.3-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
hylafax+-5.5.3-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.