Bug 430808

Jonathan, here's the answer I gave when Mike McGrath (Red Hat) asked the same
question. I also CCed the varnish-dist list, see
http://varnish.projects.linpro.no/wiki/MailingLists

As to the last paragraphs, the upstream guys answered that that making the
varnish 2.x compatible with 1.x  vcl would be very difficult, and so, this would
not be done.

As for now, I'm going to wait a bit more to see if any final roadmap for the 2.0
release will appear. If this does not happen in a few months, I'll reconsider.

Ingvar





* 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.

Ingvar

Varnish is now available in epel for EL4 and EL5.


$ yum -d0 info varnish
Available Packages
Name   : varnish
Arch   : x86_64
Version: 2.0.2
Release: 1.el5
Size   : 246 k
Repo   : epel
Summary: Varnish is a high-performance HTTP accelerator
Description:
This is the Varnish high-performance HTTP accelerator. Documentation
wiki and additional information about Varnish is available on the following
web site: http://www.varnish-cache.org/