Varnish and EPEL

Ingvar Hagelund ingvar at linpro.no
Mon Apr 28 09:29:18 CEST 2008


* Mike McGrath
> We're looking at using Varnish for Fedora's infrastructure but our front
> end servers presently are running RHEL.  What would it take to get varnish
> into EPEL-5?

Hello, Mike. I CC the varnish-dist list as this is right up their (our) 
path.

I have got several requests for Varnish in EPEL the last months. We 
should probably be flattered :-)  I discussed this a bit a while ago 
with some of the EPEL guys on IRC. There are some hurdles:

Maintaining a stable version of some fast moving software project for 
RHEL (or EPEL) is quite different from wrapping up upstream releases for 
Fedora, as Red Hat know everything about. It's what they make business 
from, after all. Long time support is the major point.

The released version of Varnish (the one that is in Fedora), is a 1.x 
version. 2.0 is on the stairs, or will be in a few months. Most of the 
users that use Varnish in heavy production are using some version of SVN 
TRUNK as there are new functionality in pre-2.0 that are very welcome 
for sites that have more than just a plain-file backend. The upstream 
developers say that they will retain focus on 2.0 and beyond, and will 
probably not continue to support 1.x in the future.

This means that if I package the Fedora version now, varnish-1.1.2 will 
go into EPEL. It will be upgraded to 1.2 in a few weeks, and probably 
then get abandoned in a few months. Who will make security fixes when 
the first bugs arrive? If security bugs are found in 2.x, there is no 
automatic check of the 1.x sources, and if this is pointed out by third 
parties, fixes will not be backported to the 1.x tree by the upstream 
developers. I am no C coder, and could probably not do it. A future 
EPEL security team would have to take responsibilty for a piece of 
software that would be unsupported, and probably abandoned by most 
users, as 2.0 is what the users, including Red Hat, would like to use in 
production.

So, what to do? There are few choices:

1) Package varnish-1.x for EPEL and keep it updated in the future.
    Someone other than me has to take security responsibility for it.
    Most users will want to use 2.0 when it is released.

2) Package varnish-1.x for EPEL, pretend it doesn't matter,
    and upgrade to 2.0 when it arrives.

    This will break all vcl configs as at least one of the main
    vcl configuration items has changed and is not upwards compatible.

    Could this be automatically patched? If all vcl files had fixed
    filenames, this could be changed "the Debian way" by patching the
    vcl files inline while upgrading. This would probably break a lot of
    systems, and we don't want that. The vcl files may be scattered
    around and loaded at run time by the admin tool too, so we don't
    even know what files to change. Nope, that won't do.

    This choice gives us a nice package that will be put in production
    over the world, and then we will have to break a lot of systems,
    and get a lot of angry users. Sound like a bad idea to me.

    Of course, a posting in the README and changelog on how to fix
    the upgrade will be appropriate for most advanced users, but
    a semi-automatic rpm upgrade will break systems for those who
    have installed Varnish and are not in that category.

    If I should have to package for EPEL today, I would probably go for
    this option anyway. It's also what the EPEL team themselves would
    suggest, I think, after I read their guidelines and discussed
    the matter with them.

3) Postpone EPEL packaging of Varnish until 2.0 is released. Solves
    most problems except for those that want to use Varnish today,
    and are not familiar with compiling and patching themselves.

3) Package a pre-2.0 svn version, and update it from time to time
    until 2.0 is relased. More than a bit risky, I guess.

4) Nag the upstream developers to include support for old-style vcl
    configuration, making old configurations upwards compatible, and
    upgrading from 1.x to 2.0 a no-brainer.

Other solutions may be to split the package in varnish1 and varnish2, 
add warnings about broken vcl in large letters in the sysinit scripts, 
or even more creative tips.

Dag-Erling, do you have any thoughts on this?

Stig, how wil this be solved in Debian?


Ingvar

-- 
Buddha wears an iPod


More information about the varnish-dist mailing list