On 05/07/2013 04:46 AM, Fajar A. Nugraha wrote:
On Tue, May 7, 2013 at 4:28 AM, John Dennis <jden...@redhat.com
<mailto:jden...@redhat.com>> wrote:
These project maintained build configurations are best thought of as
"bleeding edge developer stuff". Make some change and you want to
test on Fedora or Debian and need packages, then these build
directories are the goto place, Or for those cases where a
distribution has not caught up with upstream yet, then this can
serve a useful purpose as well (as long as they stay generic, see
below), another variant of the "this is only for the latest and
greatest".
You've pretty much covered it.
My suggestion is for upstream FreeRADIUS to maintain a generic Red
Hat RPM spec file which is vanilla as possible without any patches
whatsoever. In theory current upstream shouldn't need patches. Also
any customization we might do really should come from us, not
upstream. If one is building an RPM from the current FreeRADIUS
version using the FreeRADIUS RPM spec file then one should get a
vanilla FreeRADIUS build whose only customization extends to
assuring the same file locations, package names, etc. are used. You
pretty much get this for free. I would take an existing spec file
strip out all the patches, changelog, etc. and then one only needs
to take a look at the options passed to configure (I'm thinking
about options which control which modules are built).
IMHO some of it (e.g. changelog, patches for cert config) is/was necessary.
Yes, this is sensible. My suggestion was mostly aimed at simplifying the
task with the hope it would then be more robust and easier to maintain.
My use case was that I wanted the build to be as much drop-in as
possible, so I can (for example) upgrade to 2.2.1 as soon as possible
when it comes out, but switch to Red Hat's official RPM when it's
available, without having to change my config. Without some of the
patches, I'd need to modify my config file as well.
I think the only thing of consequence we customize is the bootstrap cert
creation which is done via RPM during the install step (plus tweaking
some of the cert parameters to tighten up security).
Any other patches are bug fixes found either by our QA team or
customers. Those are usually break down into one of two categories.
Fixes upstream has made post release and we've 'backported' or fixes
we've made and have submitted to the project. The lifetime of these
patches is short because in almost every instance the next upstream
release has addressed the issue. Kudos to the team for that. So my
thought was if you didn't try to mirror that patch set it would be much
easier and little would be lost.
Would we like to maintain the ./redhat subdirectory?
No, for two reasons.
1. It's impossible, as pointed out above there is no single spec
file, each spec file is tied to a specific release. We maintain
*independent* spec files for *every* distribution version we
support, at the moment that numbers in the dozens :-(
Yeah. Before 2.2.0 was out, I made sure that I can build RPMs for RHEL5
and 6 (because that's what I use), and submit the necessary changes
upstream. It seems to be enough (i.e. those two versions made up for
most who need to build a Red Hat RPM), because IIRC there hasn't been a
mail to the list about "I need to build FR 2.2.0 RPM for X flavor or Red
Hat but the included spec file doesn't work".
Currently the biggest pain point is the transition from SysV initscripts
to systemd. How daemons are installed and configured is different
between Fedora and RHEL at the moment and because systemd is still in a
bit of flux things can be different even between Fedora releases.
Differences in BuildRequires occur less often, but do occur.
There is a everlasting debate as to whether it's best to maintain one
spec file thats common across distributions and parameterize so that it
behaves differently in different targets or whether it's best to
maintain completely different spec files and merge changes across them.
Those who argue for merging cite the complexity of parameterized spec
files complaining all that conditional logic is difficult to work with
and fragile making it difficult to maintain. Those who argue for
parameterizing cite how merging is fragile and is difficult to maintain.
So obviously there isn't one right way. But because we're so constrained
as to what can appear in RHEL (every change has to have numerous
approvals) I gave up on trying to use Fedora spec files in RHEL and
instead merge the leading edge Fedora into RHEL.
2. We already maintain them and they are publicly available for
anyone to download. Trying to maintain multiple copies in multiple
repositories and assuring they all stay in sync doesn't seem justified.
Thanks for the effort.
If no one else does this first, I'd probably submit patches to make FR
debs and RPMs build cleanly before 2.2.1 is out (need to dig out my lxc
templates first). That way at least people can build packages for
released version.
Thank you Fajar for you good work and contributions to the FreeRADIUS
community.
--
John Dennis <jden...@redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
