FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 05-30-2008, 10:10 PM
Jason L Tibbitts III
 
Default Hylafax review issues

One of the oldest review tickets still open is
https://bugzilla.redhat.com/show_bug.cgi?id=188542, for the fax server
hylafax. Earlier this month I picked this up an attempt to try and
shepherd it through the process, but I'm stuck on a couple of issues
and the submitter does not seem to be willing to address them
satisfactorily. Maybe I should just say "hell no" and drop the
review, but I guess my objections could be wrong so I figured I'd try
to start some discussion.

Issue one is the name: There are multiple pieces of software claiming
to be hylafax. There's the software at hylafax.org, and then there's
the package at hylafax.sourceforge.net, where it is called
"hylafax+". I quote:
The "+" means that it is better.

There's also an "enterprise" version from ifax.com. The second
version, which upstream calls itself "hylafax+" is the one being
submitted, but the submitter argues against using that name (see
comment 38):
However, my suggestion would follow what I've said above about the
Apache http server. The distinction of the "+" will mean very
little to Fedora users (and in-fact may make the package
more-difficult to identify) unless there is more than one HylaFAX
package being distributed by Fedora (say, for example, separate
"hylafax+" and "hylafax.org" packages).

Anyone else agree with that reasoning? What about using
Provides: hylafax
until the hylafax.org package makes it into the distro (assuming
someone actually wants to submit it)?

The second issue is an FHS violation: several directories are
installed under /var/spool which contain things that aren't really in
the spirit of /var/spool. There's a /var/spool/hylafax/bin directory
which, you guessed it, contains executables, a
/var/spool/hylafax/config directory containing config files, and
/var/spool/hylafax/etc containing other, different config files.

Here's what the submitter has to say (see comment 83):
While the vast majority of HylaFAX binaries and their respective
configuration files are installed outside of /var/spool/hylafax,
those three directories (etc, bin, and config) are configuration
files and configuration utility scripts, etc., that control how the
spools are handled.

Due to the way that HylaFAX daemons operate it would be extremely
cumbersome (if not impossible - as in the case of a chroot) for
these to be elsewhere. They're very much like the configuration
files that LPRng had under /var/spool/lpd.

So, that's my argument. I hope that it's acceptable. But if it's
not... unfortunately there's not much that I am willing to do about
it.

Now, lprng isn't in the distro and I really don't think it would have
passed review like that, so I can't buy that as an argument.
"cumbersome", well, too bad I guess. I'm not sure about a chroot. I
mean, just fix the code to look elsewhere. How hard could it be?

But even if, it's too hard to fix, what about a few symlinks? (To
somewhere under /usr/libexec for the bin stuff, and somewhere under
/etc for for config and etc directories.) Do three symlinks violate
the FHS significantly enough to cause issues? My understanding is
that this should be OK with chroots (as long as the links are
relative.) And how does all of this square with selinux?

I'd be appreciative of any suggestions.

- J<

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-31-2008, 01:04 PM
Hans de Goede
 
Default Hylafax review issues

Jason L Tibbitts III wrote:

One of the oldest review tickets still open is
https://bugzilla.redhat.com/show_bug.cgi?id=188542, for the fax server
hylafax. Earlier this month I picked this up an attempt to try and
shepherd it through the process, but I'm stuck on a couple of issues
and the submitter does not seem to be willing to address them
satisfactorily. Maybe I should just say "hell no" and drop the
review, but I guess my objections could be wrong so I figured I'd try
to start some discussion.

Issue one is the name: There are multiple pieces of software claiming
to be hylafax. There's the software at hylafax.org, and then there's
the package at hylafax.sourceforge.net, where it is called
"hylafax+". I quote:
The "+" means that it is better.

There's also an "enterprise" version from ifax.com. The second
version, which upstream calls itself "hylafax+" is the one being
submitted, but the submitter argues against using that name (see
comment 38):
However, my suggestion would follow what I've said above about the
Apache http server. The distinction of the "+" will mean very
little to Fedora users (and in-fact may make the package
more-difficult to identify) unless there is more than one HylaFAX
package being distributed by Fedora (say, for example, separate
"hylafax+" and "hylafax.org" packages).

Anyone else agree with that reasoning?


I tend to agree that plain hylafax is the right name for a couple of reaons:
1) hylafax is quite well known so I would expect "yum install hylafax" to just
work, but also something like rpm -q hylafax. Note that the quite well
known-ness also is an argument to get this thing reviewed and included it
really is a shame that Fedora currently does not have a hylafax package,
so Jason good work on trying to get this through review!

2) When in doubt about things like Casing or cases like this I always look at
the source tarbal name, and that in this case is plain hylafax, not hylafax+
changing the name would mean that a -n argument would be needed to %setup,
also notice that the installed binaries, service, etc are all called hylafax
without the +.


The second issue is an FHS violation: several directories are
installed under /var/spool which contain things that aren't really in
the spirit of /var/spool. There's a /var/spool/hylafax/bin directory
which, you guessed it, contains executables, a
/var/spool/hylafax/config directory containing config files, and
/var/spool/hylafax/etc containing other, different config files.

Here's what the submitter has to say (see comment 83):
While the vast majority of HylaFAX binaries and their respective
configuration files are installed outside of /var/spool/hylafax,
those three directories (etc, bin, and config) are configuration
files and configuration utility scripts, etc., that control how the
spools are handled.

Due to the way that HylaFAX daemons operate it would be extremely
cumbersome (if not impossible - as in the case of a chroot) for
these to be elsewhere. They're very much like the configuration
files that LPRng had under /var/spool/lpd.

So, that's my argument. I hope that it's acceptable. But if it's
not... unfortunately there's not much that I am willing to do about
it.

But even if, it's too hard to fix, what about a few symlinks? (To
somewhere under /usr/libexec for the bin stuff, and somewhere under
/etc for for config and etc directories.) Do three symlinks violate
the FHS significantly enough to cause issues? My understanding is
that this should be OK with chroots (as long as the links are
relative.) And how does all of this square with selinux?



I tend to agree with you on this one, but having just packaged coda I know how
non FHS compliant locations can sometimes be hardcoded all over the place (no
not as easy as a singel define somewhere, paths written fully all over the place).


So I'm somewhat sympathetic to the submitters arguments, have you suggested the
symlink approach to him?


Regards,

Hans

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-31-2008, 04:12 PM
Jason L Tibbitts III
 
Default Hylafax review issues

>>>>> "HdG" == Hans de Goede <j.w.r.degoede@hhs.nl> writes:

HdG> hylafax is quite well known so I would expect "yum install
HdG> hylafax" to just work, but also something like rpm -q hylafax.

Well, I'd certainly agree, if this was actually the hylafax software.
But it's not; it's the hylafax+ software. I'll freely admit that
nobody so far has tried to get the hylafax sotfware into Fedora, and
perhaps that will never happen. If we assume that it will never
happen, then we have no conflict and I suppose we don't care. I'm not
sure that we can make this assumption, though.

I'm trying to think of a situation where an upstream fork with a
slightly different name tries to get itself into a distro with the
original name in (what seems to me to be) an attempt to gain
legitimacy. I don't think it's happened before, and we should avoid
hastily taking a precident-setting position.

HdG> 2) When in doubt about things like Casing or cases like this I
HdG> always look at the source tarbal name, and that in this case is
HdG> plain hylafax, not hylafax+ changing the name would mean that a
HdG> -n argument would be needed to %setup, also notice that the
HdG> installed binaries, service, etc are all called hylafax without
HdG> the +.

Well, that's just the nature of the upstream, though. Their web site
is plain about the naming and there's a reasonable argument (already
made in the review ticket) that their tarballs are misnamed. I think
the nature of forks will generally result in situations as we have with
the binaries.

HdG> So I'm somewhat sympathetic to the submitters arguments, have you
HdG> suggested the symlink approach to him?

I have not; I wanted to see how reasonable others thought the approach
was before proposing it, having him do the work and then getting
flamed for it in the review ticket.

- J<

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-31-2008, 05:23 PM
Hans de Goede
 
Default Hylafax review issues

Jason L Tibbitts III wrote:

"HdG" == Hans de Goede <j.w.r.degoede@hhs.nl> writes:


HdG> hylafax is quite well known so I would expect "yum install
HdG> hylafax" to just work, but also something like rpm -q hylafax.

Well, I'd certainly agree, if this was actually the hylafax software.
But it's not; it's the hylafax+ software. I'll freely admit that
nobody so far has tried to get the hylafax sotfware into Fedora, and
perhaps that will never happen. If we assume that it will never
happen, then we have no conflict and I suppose we don't care. I'm not
sure that we can make this assumption, though.



Well the question here IMHO is not so much how to name the package as it is
which fork to package, making them parallel installable will be very hard todo
and AFAIK we don't want conflicting packages. Now reading this imho pretty
neutral description of the various forks:

http://en.wikipedia.org/wiki/HylaFAX

I believe that hylafax+ best fits Fedora.

Regards,

Hans

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-31-2008, 05:25 PM
"Joe Harnish"
 
Default Hylafax review issues

>
> I'm trying to think of a situation where an upstream fork with a
> slightly different name tries to get itself into a distro with the
> original name in (what seems to me to be) an attempt to gain
> legitimacy. I don't think it's happened before, and we should avoid
> hastily taking a precident-setting position.

The one package that could have a similar problem is jabberd and
jabberd2. They are two separate yet actively developed projects
(http://en.wikipedia.org/wiki/Jabberd).

--Joe

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-31-2008, 07:00 PM
Jason L Tibbitts III
 
Default Hylafax review issues

>>>>> "HdG" == Hans de Goede <j.w.r.degoede@hhs.nl> writes:

HdG> Well the question here IMHO is not so much how to name the
HdG> package as it is which fork to package, making them parallel
HdG> installable will be very hard todo and AFAIK we don't want
HdG> conflicting packages.

I agree that it would be very difficult to make them able to be
installed at the same time, but if the hylafax authors or some other
interested party decided to submit their software I don't see why we'd
turn them away just because someone who forked their package decided
not to change the name of the binaries.

HdG> I believe that hylafax+ best fits Fedora.

I don't see any point in attempting to decide which of many choices
fits Fedora; hylafax+ is simply the only one that's been submitted.

For comparison, Debian and Ubuntu don't seem to ship hylafax+; they
ship hylafax and in addition split the package into -client, -server
and -doc subpackages (which may be worth considering here).

Gentoo has ebuilds for both hylafax and hylafax+ named accordingly.

I'm not sure how to check Suse.

Also of some importance, I think, is the fact that you can visit
hylafax.org and download source and binary packages for Fedora (up to
F7 at least) and they're named, you guessed it, "hylafax". I've no
clue why they haven't submitted them to Fedora proper, but the folks
who do (or maybe sponsor) that packaging work actually request that
the hylafax+ package be named "hylafax+".
http://www.hylafax.org/content/Fedora_Packages

- J<

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-31-2008, 07:08 PM
Hans de Goede
 
Default Hylafax review issues

Jason L Tibbitts III wrote:

"HdG" == Hans de Goede <j.w.r.degoede@hhs.nl> writes:


HdG> Well the question here IMHO is not so much how to name the
HdG> package as it is which fork to package, making them parallel
HdG> installable will be very hard todo and AFAIK we don't want
HdG> conflicting packages.

I agree that it would be very difficult to make them able to be
installed at the same time, but if the hylafax authors or some other
interested party decided to submit their software I don't see why we'd
turn them away just because someone who forked their package decided
not to change the name of the binaries.

HdG> I believe that hylafax+ best fits Fedora.

I don't see any point in attempting to decide which of many choices
fits Fedora; hylafax+ is simply the only one that's been submitted.

For comparison, Debian and Ubuntu don't seem to ship hylafax+; they
ship hylafax and in addition split the package into -client, -server
and -doc subpackages (which may be worth considering here).

Gentoo has ebuilds for both hylafax and hylafax+ named accordingly.

I'm not sure how to check Suse.

Also of some importance, I think, is the fact that you can visit
hylafax.org and download source and binary packages for Fedora (up to
F7 at least) and they're named, you guessed it, "hylafax". I've no
clue why they haven't submitted them to Fedora proper, but the folks
who do (or maybe sponsor) that packaging work actually request that
the hylafax+ package be named "hylafax+".
http://www.hylafax.org/content/Fedora_Packages



Hmm, I don't see them requesting that anywhere, or have you been in direct
contact with them?


Anyways, yes there are some arguments to call the package hylafax+. to be
honest, here is whats in my mind the best solution:

call hylafax+ package hylafax+
call hylafax original package (if we get one ever) hylafax.org

Don't call any package ever hylafax as with all the forks thats to ambigious.

Make hylafax+ provide hylafax for easy install, dunno what todo if we get a
hylafax.org too, but lets worry about that later. Now we need to sell this to
the submitter of the package though.


Regards,

Hans

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-31-2008, 08:10 PM
Toshio Kuratomi
 
Default Hylafax review issues

Jason L Tibbitts III wrote:

One of the oldest review tickets still open is
https://bugzilla.redhat.com/show_bug.cgi?id=188542, for the fax server
hylafax. Earlier this month I picked this up an attempt to try and
shepherd it through the process, but I'm stuck on a couple of issues
and the submitter does not seem to be willing to address them
satisfactorily. Maybe I should just say "hell no" and drop the
review, but I guess my objections could be wrong so I figured I'd try
to start some discussion.

Issue one is the name: There are multiple pieces of software claiming
to be hylafax. There's the software at hylafax.org, and then there's
the package at hylafax.sourceforge.net, where it is called
"hylafax+". I quote:
The "+" means that it is better.

There's also an "enterprise" version from ifax.com. The second
version, which upstream calls itself "hylafax+" is the one being
submitted, but the submitter argues against using that name (see
comment 38):
However, my suggestion would follow what I've said above about the
Apache http server. The distinction of the "+" will mean very
little to Fedora users (and in-fact may make the package
more-difficult to identify) unless there is more than one HylaFAX
package being distributed by Fedora (say, for example, separate
"hylafax+" and "hylafax.org" packages).

Anyone else agree with that reasoning? What about using
Provides: hylafax
until the hylafax.org package makes it into the distro (assuming

someone actually wants to submit it)?

From reading the review top to bottom I think Lee is willing to name
the Fedora package hylafax+, just not the upstream tarball. I don't
know why he hasn't done that yet except perhaps no one has said, "yes
please do it that way".


I would okay the Provide: hylafax as long as there's no other hylafax in
the distro. Once there is we'd have to decide what to do --
alternatives for postfix uses full paths to binaries, MTA,server(smtp),
smtpd, smtpdaemon. "sendmail" is not provided. Perhaps hylafax.org
could be added as hylafax.org similar to xorg and openoffice.org and
"hylafax" can be equivalent to sendmail's generic provides.



The second issue is an FHS violation: several directories are
installed under /var/spool which contain things that aren't really in
the spirit of /var/spool. There's a /var/spool/hylafax/bin directory
which, you guessed it, contains executables, a
/var/spool/hylafax/config directory containing config files, and
/var/spool/hylafax/etc containing other, different config files.

Here's what the submitter has to say (see comment 83):
While the vast majority of HylaFAX binaries and their respective
configuration files are installed outside of /var/spool/hylafax,
those three directories (etc, bin, and config) are configuration
files and configuration utility scripts, etc., that control how the
spools are handled.

Due to the way that HylaFAX daemons operate it would be extremely
cumbersome (if not impossible - as in the case of a chroot) for
these to be elsewhere. They're very much like the configuration
files that LPRng had under /var/spool/lpd.

So, that's my argument. I hope that it's acceptable. But if it's
not... unfortunately there's not much that I am willing to do about
it.

Now, lprng isn't in the distro and I really don't think it would have
passed review like that, so I can't buy that as an argument.
"cumbersome", well, too bad I guess. I'm not sure about a chroot. I
mean, just fix the code to look elsewhere. How hard could it be?

This one's much harder. It must be fixed. I took a look at the Debian
package (they have hylafax.org and not hylafax+) and they do a copy on
startup of the config files. that's not ideal but it's similar to the
symlink idea. The Debian package doesn't mention the binaries so I
assume they remain in /var/spool.


This only addresses one concern of the FHS, though: that config files
have a canonical place on the filesystem for users to find them.


Three other programs I know we ship that have chroot operation are
postfix, scponly, and bind:


postfix does not ship with a chroot configuration in Fedora. In order
to enable the chroot, you have to change the configuration file. The
instructions will place the chroot in the /var/spool/postfix directory.
You have to copy the files that the programs need to operate in the
chroot jail yourself and maintain them as updates come out.


scponly is similar. It doesn't have any specific directory by default
so you can set the chroot to be any set of directories on the system but
you still have to build and maintain the chroot yourself.


bind has a package bind-chroot that sets up in /var/named/chroot. It
includes a new copy of the conf files, data directories, etc. These are
separate from the files that come with the normal bind package.


Based on these existing packages the right thing to do in Fedora seems
to be: follow the FHS even if it prevents chroots. If the author of the
package wants chroots for Fedora, supply a subpackage or a script that
sets up and maintains the chroot.



But even if, it's too hard to fix, what about a few symlinks? (To
somewhere under /usr/libexec for the bin stuff, and somewhere under
/etc for for config and etc directories.) Do three symlinks violate
the FHS significantly enough to cause issues? My understanding is
that this should be OK with chroots (as long as the links are
relative.) And how does all of this square with selinux?


Yeah, need an SELinux person to weigh in here.

-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-01-2008, 06:44 AM
Ralf Corsepius
 
Default Hylafax review issues

On Sat, 2008-05-31 at 14:00 -0500, Jason L Tibbitts III wrote:
> >>>>> "HdG" == Hans de Goede <j.w.r.degoede@hhs.nl> writes:
>
> HdG> Well the question here IMHO is not so much how to name the
> HdG> package as it is which fork to package, making them parallel
> HdG> installable will be very hard todo and AFAIK we don't want
> HdG> conflicting packages.

> HdG> I believe that hylafax+ best fits Fedora.
>
> I don't see any point in attempting to decide which of many choices
> fits Fedora; hylafax+ is simply the only one that's been submitted.
ACK.

> For comparison, Debian and Ubuntu don't seem to ship hylafax+; they
> ship hylafax and in addition split the package into -client, -server
> and -doc subpackages (which may be worth considering here).
>
> Gentoo has ebuilds for both hylafax and hylafax+ named accordingly.
>
> I'm not sure how to check Suse.
SuSE ships "hylafax", originating from www.hylafax.org's hylafax-4.*
tarballs with many patches having been added.

Ralf



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-01-2008, 06:30 PM
Jason L Tibbitts III
 
Default Hylafax review issues

>>>>> "HdG" == Hans de Goede <j.w.r.degoede@hhs.nl> writes:

HdG> Hmm, I don't see them requesting that anywhere, or have you been
HdG> in direct contact with them?

It was requested in the review ticket:
https://bugzilla.redhat.com/show_bug.cgi?id=188542#c35

- J<

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 04:57 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org