On Wed, Feb 25, 2009 at 03:34:14PM -0700, John Hein wrote:
> stan wrote at 16:13 -0500 on Feb 25, 2009:
> > It appears that the mainstream development of Amanda has taken off in a
> > direction that has/will result in making in impossible to compile on many
> > existing platforms that have been historically supported by Amanda.
> >
> > While there are good reasons for this change, it represents a major loss of
> > functionality for us, and I suspect many other long term Amanda users who
> > depend on being able to use this package to backup their older clients.
> >
> > I have been discussing this issue at length, off list, with one of the
> > developers of the project. His recommendation is that we create a "client
> > only" version of Amanda that is a fork off of the 2.5.2.x branch of th
> > tree. This version, as I understand it predates the need for glibc, which
> > as I have just discovered is unsorted on may many hardware/software
> > architectures. I think it also predates the need for pkg-configure, which
> > does not seem to have the same portability issues as glib, but is IMHO an
> > unnecessary build time dependency, given that configure was designed for,
> > what I believe to be, the same need.
> >
> > I am thinking about volunteering to lead this effort, as we are in the
> > middle of upgrading a fairly large Amanda installation at my work, and i
> > have, at least, 3 OS/hardware pairs thta are not supported by glib.
> >
> > I would like to hear from other users of Amanda how they feel about this. i
> > hope the collective wisdom of the list may help to provide some direction
> > for my thoughts.
>
> I am sympathetic to the needs of running old platforms.
>
> But if you need to do so, at a certain point, it becomes an exercise of
> self-maintenance. It's like maintaining a 50 year old car. You can't
> just go to Napa and get a part sometimes.
If we were talking about a free standing project that supported new
functionality here, I would agree. But Amanda is in a somewhat unique
position, as it is a support project that touches (potentially) all the
machines at a site. backup is the most basic functionality that must be
supported on all the machines on a site. While mentoring, as provided by
nagios, cricket, cacti, etc. does touch (potentially) all the systems at a
site, i can justify not having a neat new monitoring feature work on an
older system. I cannot say to my management. Oh yeah that system that
running the bossiness depends on is old, and I can't back it up. Not and
keep my job :-)
>
> Developing for a project like amanda is, to some extent, a juggling
> exercise. They (the developers) have to deal with a variety of OS's
> of various ages. I can understand the decision to depend on glib (not
> glibc, BTW) from a portability aspect. (I'm less convinced about
> perl, but that's another matter).
Well, i understand that the current developers are more comfortable with
code that is more widely deployed, and thus hopefully more tested, and
debugged than the existing code in the Amanda codebase. I personally am a big
believer in the "if it isn't broke, don't fix it" philosophy, but that is
neither here or there. I was confused about glibc, versus glib, and now
that I understand this, I am hoping that I can get glib compiled on various
old machines. Still, I'd rather not have to do that, when we are simply
changing things to suit the developers "style". The dependency on (a very
current) version of perl, and the addition of Amanda specific perl modules,
and shared libraries is a much bigger concern to me, as Perl's default way of
installing modules will break them whenever perl is upgraded. On the more
modern systems, such as Unbuntu, which we routinely install the security
patches on, I am concerned about breaking Amanda when I do a simple security
upgrade. I have managed to use configure flags to install Amanda's perl
modules in a place that I hope will prevent this from happening, but all of
this amounts to a strong desire to have a more portable, and stable version
of the clients.
While I think adding functionality to the server is a good thing, I would
prefer that stability was a higher priority for the client side software. At
least for the older machines.
>
> glib was partly chosen _because_ it's more portable (again not glibc),
> but it can sometimes have edge cases when using it on older systems.
>
> This is a much more general question that applies to more than
> just amanda.
>
> But, that said, there is some effort expended to ensure that newer
> amanda servers can speak to older clients (going the other way, new
> client - old server, is another matter, but that works to a certain
> extent, too). So for older platforms, you _can_ (as others have
> mentioned) just freeze the amanda version on the client. Most, but
> not all, of the new features one would be interested in are on the
> server.
>
> Answering your particular notion of forking amanda, it's also another
> possibility to expend some effort to build the latest amanda on an old
> system. If you don't have to build the server code, it's a more
> simplified task. And if you have a set of patches to say, build on
> old HP-UX, sometimes they can be applied in the current code (submit
> to amanda-hackers). At the least, you can put the patches up on the
> wiki. Anyway, that's another possibility for you to consider.
>
I am concerned that doing that will be a rucuring nightmare, whereas
creating an Amanda client sub project that is focused on portability, and
stability will, I believe, in the long run, result in a better solution.
Thanks for your thoughts.
--
One of the main causes of the fall of the roman empire was that, lacking
zero, they had no way to indicate successful termination of their C
programs.
|
