Need help with making RPM from v2.x.x branch

[John Dennis]

On 05/07/2013 04:46 AM, Fajar A. Nugraha wrote:
> On Tue, May 7, 2013 at 4:28 AM, John Dennis <jdennis at redhat.com
> <mailto:jdennis at 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 <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/