On 8/17/06, Lars Marowsky-Bree <[EMAIL PROTECTED]> wrote:
On 2006-08-17T15:24:46, Monty Taylor <[EMAIL PROTECTED]> wrote:
> >Maybe some of the changes I made for the openSUSE package are
> >interesting to you? http://repos.opensuse.org/server:/ha-clustering/
>
> I'm going to look at that this evening. Maybe we can have one magic spec
> file!
That is my personal goal, too. openSUSE, despite its name, not only
builds for openSUSE 9.3, 10.0, 10.1, SLES9 + SLES10, but also Xubuntu,
Fedora 4 + 5, and Mandriva. Maybe more in the future. I'll plod through
this and hopefully, eventually arrive at a specfile which builds on all
of these.
(This is my copious spare time, because for some reason or the other, my
employer mostly cares about SLES 10 ;-)
Go figure. My employer typcially doesn't care about debian builds
because most of our paying customers are on RHEL - although all of our
European devs run SLES, so that get's attention from us to.
If you want to help with that, we ought to get you an account on the
openSUSE build system.
I'd love to help out with a single-source build process (or at least a
dual-source, since the debian build process is 100% different.) I
think our companies are supposed to be partners or something, so maybe
it won't be too hard to justify.
(And even builds Debian Etch, but that requires Debian magic I'm not up
to right now.)
Thats ok. I'm a Debian developer, so I can help out if it's needed
(even though I don't have an account - it's not for lack of skill or
trying, more due to a lack of time. I haven't tested the debian build
process since recent versions of heartbeat actually exist in Ubuntu.
:)
One of the main advantages is that spec files do tend to set something
which allows you to guess the version you're building on - suse has
sles_version and suse_version, for example. I need to find out, in my
copious spare time, what other distributions use.
Good! That's a nice start, at least.
> >> +CFLAGS="${RPM_OPT_FLAGS} -fno-unit-at-a-time" \
> >Why hard-code -fno-unit-at-atime here? I don't like that.
> I really just moved it. It was there for some reason that I didn't
> understand, so I just kept it.
Hrm. Interesting. I don't know where that came from then either.
> I second that. :) I'll work on your suggestions and get a new diff
> against the current (CVS head?) source.
Depends. CVS HEAD of course works too, but the .in file probably isn't
the best choice, as it gets mangled by configure.
It's easier for me to merge changes into the build service if it's diffs
against that, of course. ;-)
If ultimately the goal is to converge on a single unified spec file for
all rpm based distros going forward, it ultimately doesn't matter
either, as it replaces them all. So, we might consider this a clean
slate, too.
I'm a big fan of unified build processes, so that when I'm at a client
site and setting up heartbeat I don't have to keep in mind all of the
differences between the different platforms.
I think it's apparently a dual-goal, though. Unified spec files, and
making sure it can work the old way so Alan won't be upset.
(respecting project leader wishes and all)
Monty
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
