Bug 890660 - hylafax+ RPM replaces other hylafax RPM installations
Summary: hylafax+ RPM replaces other hylafax RPM installations
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: hylafax+
Version: rawhide
Hardware: All
OS: All
unspecified
urgent
Target Milestone: ---
Assignee: Lee Howard
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-28 15:24 UTC by Robert Scheck
Modified: 2013-03-29 01:37 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-03-19 21:28:03 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Robert Scheck 2012-12-28 15:24:22 UTC
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.

Comment 1 Robert Scheck 2012-12-28 15:31:43 UTC
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.

Comment 2 Lee Howard 2012-12-30 00:08:10 UTC
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?

Comment 3 Lee Howard 2012-12-30 03:35:04 UTC
Another good example would be that of openoffice vs. libreoffice.  I note the Provides in the libreoffice SPEC file.

Comment 4 Robert Scheck 2012-12-30 14:32:53 UTC
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.

Comment 5 Lee Howard 2012-12-31 02:01:58 UTC
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?

Comment 6 Fedora Update System 2013-02-26 07:03:36 UTC
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

Comment 7 Fedora Update System 2013-02-26 07:16:49 UTC
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

Comment 8 Fedora Update System 2013-02-26 07:38:08 UTC
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

Comment 9 Fedora Update System 2013-02-26 07:50:34 UTC
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

Comment 10 Fedora Update System 2013-02-26 19:16:53 UTC
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).

Comment 11 Fedora Update System 2013-03-19 21:28:04 UTC
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.

Comment 12 Fedora Update System 2013-03-19 21:28:43 UTC
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.

Comment 13 Fedora Update System 2013-03-20 21:58:37 UTC
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.

Comment 14 Fedora Update System 2013-03-29 01:37:04 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.