[libvirt] Release of libvirt-0.8.7

[Laine Stump]

(adding netcf-devel to the Cc list)

On 01/06/2011 10:02 PM, Patrick Mullaney wrote:
> On Thu, 2011-01-06 at 17:00 -0700, Jim Fehlig wrote:
>> Laine Stump wrote:
>>> As far as I know, the SuSE port was actually complete at one time, and
>>> was included in a released product (not sure what the product is),
>> It hasn't been included in a product yet, but might be in upcoming
>> openSUSE 11.4.
> Right. As far as I know, it should be in opensuse 11.4. I haven't
> heard otherwise. My plan was to upstream the patches but I got
> sidetracked with some other projects.

Ah, you're talking about a completely different effort - the SuSE port I 
was talking about is referenced here:

   https://fedorahosted.org/pipermail/netcf-devel/2009-June/000092.html

I pinged Jonas about it a couple months ago, and learned that they had 
updated their patches and were actually using it (when I said "product", 
I wasn't talking about the OS itself, but something based on the OS), 
but hadn't had the resources to clean it up for upstream.

After searching the list archives for mail from Patrick, I now see this 
message:

https://fedorahosted.org/pipermail/netcf-devel/2010-May/000415.html

(and a response from David Lutterkort), and even recall reading it, but 
when I went through old mail in the Fall looking for people doing 
porting work, I found the earlier messages from Jonas first and sent him 
mail, then neglected to continue looking for other people working 
separately on the same platform.

> My patches touch drv_initscripts.c, initscripts-get.xsl, and
> initscripts-put.xsl. The xsl files are slightly different because
> our ifcfg syntax is slightly different. I also have a couple new
> augeas lenses that we need for our network configuration to work.
> I'll try to apply it against head and send it out to the list soon.

It's good to hear that you've got it working. It will be nice when we no 
longer have to tell so many people on #virt "well, if your distro had 
netcf, you could do 'x', but since it doesn't, you'll need to do it by 
hand".

> How would you recommend handling the files above and the build
> for different distros? Should they just be drv_suse.c,
> initscripts-get-suse.xsl, and initscripts-put-suse.xsl and then
> changed back during the build?

If the changes to drv_initscripts.c aren't too drastic, and can easily 
be #ifdef'ed, I think it would be preferable to just keep the single 
file there, to avoid maintenance problems with duplicated code; there's 
nothing that says each supported platform needs its own drv_*.c file 
(Fedora and RHEL already use drv_initscripts.c, for example).

If you think the changes are too big (maybe it ends up with 80% of the 
file being inside #ifdefs), but there is still some common code, it 
might be appropriate to move all the non-common things out of 
drv_initscripts.c into drv_fedora-rhel.c, then have suse's build include 
both drv_initscripts.c and drv_suse.c (likewise for fedora-rhel).

(For that matter, at that point, maybe drv_initscripts.c could be 
renamed to dutil_initscripts.c (as long as there are no toplevel drv_*() 
functions), and it could maybe get some of the functions from 
dutil_linux.c that are really only applicable to initscripts-based systems.)

For the xsl files, I'm not  really competent to render an opinion there. 
I would say, though, that if it's possible to avoid duplicating 
identical parts of those files (by some sort of conditionalizing in a 
single file, or maybe splitting each file into a "common between all 
initscripts platforms" and "specific to platform a", that would be 
preferable. Otherwise, having separate files and copying them into 
"initscripts-(get|put).xsl" during the build would be fine. (If you do 
that, part of your patch should maybe be to move the current versions of 
those files into "initscripts-fedora-rhel-(get|put).xsl", and add the 
same build step to that port.)

There really are no hard/fast rules, though, as there is not yet any 
precedent.