[PATCH] Differentiate 'distro' and 'distrofamily' in Sys::Guestfs::Lib
Change distro in the output formally known as virt-inspector to reflect the actual distro. Possible values are now: fedora, rhel, centos, scientific, debian. Add new distrofamily entry which is one of: redhat, debian. Currently all distros except 'debian' are in the redhat family. This allows you to, for example, select a RHEL/CentOS/Scientific Linux specific kernel for installation rather than assuming they're all the same. --- perl/lib/Sys/Guestfs/Lib.pm | 58 ++++++++++++++++++++++++++++++++++--------- 1 files changed, 46 insertions(+), 12 deletions(-) diff --git a/perl/lib/Sys/Guestfs/Lib.pm b/perl/lib/Sys/Guestfs/Lib.pm index 925c494..df3bbe1 100644 --- a/perl/lib/Sys/Guestfs/Lib.pm +++ b/perl/lib/Sys/Guestfs/Lib.pm @@ -475,8 +475,13 @@ Filesystem content, if we could determine it. One of: "linux-grub", =item osdistro (For Linux root partitions only). -Operating system distribution. One of: "fedora", "redhat", -"debian". +Operating system distribution. One of: "fedora", "rhel", "centos", +"scientific", "debian". + +=item osdistrofamily + +(For Linux root partitions only) +Operating system distribution family. One of: "redhat", "debian". =item osversion @@ -609,20 +614,47 @@ sub _check_linux_root # Look into /etc to see if we recognise the operating system. if ($g->is_file ("/etc/redhat-release")) { + $r->{osdistrofamily} = "redhat"; + $_ = $g->cat ("/etc/redhat-release"); if (/Fedora release (\d+\.\d+)/) { $r->{osdistro} = "fedora"; $r->{osversion} = "$1" - } elsif (/(Red Hat Enterprise Linux|CentOS|Scientific Linux).*release (\d+).*Update (\d+)/) { - $r->{osdistro} = "redhat"; - $r->{osversion} = "$2.$3"; - } elsif (/(Red Hat Enterprise Linux|CentOS|Scientific Linux).*release (\d+(?:\.(\d+))?)/) { - $r->{osdistro} = "redhat"; - $r->{osversion} = "$2"; - } else { - $r->{osdistro} = "redhat"; + } + + elsif (/(Red Hat Enterprise Linux|CentOS|Scientific Linux)/) { + my $distro = $1; + + if($distro eq "Red Hat Enterprise Linux") { + $r->{osdistro} = "rhel"; + } + + elsif($distro eq "CentOS") { + $r->{osdistro} = "centos"; + } + + elsif($distro eq "Scientific Linux") { + $r->{osdistro} = "scientific"; + } + + # Shouldn't be possible + else { die }; + + if (/$distro.*release (\d+).*Update (\d+)/) { + $r->{osversion} = "$1.$2"; + } + + elsif (/$distro.*release (\d+(?:\.(?:\d+))?)/) { + $r->{osversion} = "$1"; + } + } + + else { + $r->{osdistro} = "redhat-based"; } } elsif ($g->is_file ("/etc/debian_version")) { + $r->{osdistrofamily} = "debian"; + $_ = $g->cat ("/etc/debian_version"); if (/(\d+\.\d+)/) { $r->{osdistro} = "debian"; @@ -883,6 +915,8 @@ sub _get_os_version $r->{os} = $r->{root}->{fsos} if exists $r->{root}->{fsos}; $r->{distro} = $r->{root}->{osdistro} if exists $r->{root}->{osdistro}; + $r->{distrofamily} = $r->{root}->{osdistrofamily} + if exists $r->{root}->{osdistrofamily}; $r->{version} = $r->{root}->{osversion} if exists $r->{root}->{osversion}; } @@ -1063,8 +1097,8 @@ sub _check_for_applications my $osn = $os->{os}; if ($osn eq "linux") { - my $distro = $os->{distro}; - if (defined $distro && ($distro eq "redhat" || $distro eq "fedora")) { + my $family = $os->{distrofamily}; + if (defined $family && $family eq "redhat") { my @lines = $g->command_lines (["rpm", "-q", "-a", -- 1.6.2.5
On Thu, Jul 16, 2009 at 11:54:55PM +0100, Matthew Booth wrote:
Change distro in the output formally known as virt-inspector to reflect the actual distro. Possible values are now: fedora, rhel, centos, scientific, debian.
Add new distrofamily entry which is one of: redhat, debian. Currently all distros except 'debian' are in the redhat family.
This allows you to, for example, select a RHEL/CentOS/Scientific Linux specific kernel for installation rather than assuming they're all the same.
IMHO doing this is a big mistake. This is what we did for virt-install and hugely regret it. Things just don't fall into a nice hierarchy. We are now looking at doing a flat list of distros + tagging/categorization relationships to be defined. http://www.redhat.com/archives/et-mgmt-tools/2009-June/msg00018.html Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On 17/07/09 11:21, Daniel P. Berrange wrote:
IMHO doing this is a big mistake. This is what we did for virt-install and hugely regret it. Things just don't fall into a nice hierarchy. We are now looking at doing a flat list of distros + tagging/categorization relationships to be defined.
http://www.redhat.com/archives/et-mgmt-tools/2009-June/msg00018.html
Thanks, Dan. What problems did you hit? I'm inclined to think I might get away with it for virt-v2v because we also have so much other additional info about the system. So far, 'redhat' pretty much means it uses rpm rather than anything else. Are you actually doing OS detection, or is this just for filling in distro-specific defaults? What sort of data do you have on individual distros? Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
On Fri, Jul 17, 2009 at 12:06:31PM +0100, Matthew Booth wrote:
On 17/07/09 11:21, Daniel P. Berrange wrote:
IMHO doing this is a big mistake. This is what we did for virt-install and hugely regret it. Things just don't fall into a nice hierarchy. We are now looking at doing a flat list of distros + tagging/categorization relationships to be defined.
http://www.redhat.com/archives/et-mgmt-tools/2009-June/msg00018.html
Thanks, Dan.
What problems did you hit? I'm inclined to think I might get away with it for virt-v2v because we also have so much other additional info about the system. So far, 'redhat' pretty much means it uses rpm rather than anything else.
How about instead of "distrofamily" we add flags to tell us what we actually want to know: uses_rpm uses_dpkg Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
On 17/07/09 12:21, Richard W.M. Jones wrote:
On Fri, Jul 17, 2009 at 12:06:31PM +0100, Matthew Booth wrote:
On 17/07/09 11:21, Daniel P. Berrange wrote:
IMHO doing this is a big mistake. This is what we did for virt-install and hugely regret it. Things just don't fall into a nice hierarchy. We are now looking at doing a flat list of distros + tagging/categorization relationships to be defined.
http://www.redhat.com/archives/et-mgmt-tools/2009-June/msg00018.html Thanks, Dan.
What problems did you hit? I'm inclined to think I might get away with it for virt-v2v because we also have so much other additional info about the system. So far, 'redhat' pretty much means it uses rpm rather than anything else.
How about instead of "distrofamily" we add flags to tell us what we actually want to know:
uses_rpm uses_dpkg
or, as this would be single-os specific: package_management=rpm package_management=dpkg My only concern about that scheme is that at this point we have little idea about what we need to know. I guess it won't be too hard to add it as we go along. I can make this change on Monday morning if you like. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
On Fri, Jul 17, 2009 at 12:41:04PM +0100, Matthew Booth wrote:
On 17/07/09 12:21, Richard W.M. Jones wrote:
On Fri, Jul 17, 2009 at 12:06:31PM +0100, Matthew Booth wrote:
On 17/07/09 11:21, Daniel P. Berrange wrote:
IMHO doing this is a big mistake. This is what we did for virt-install and hugely regret it. Things just don't fall into a nice hierarchy. We are now looking at doing a flat list of distros + tagging/categorization relationships to be defined.
http://www.redhat.com/archives/et-mgmt-tools/2009-June/msg00018.html Thanks, Dan.
What problems did you hit? I'm inclined to think I might get away with it for virt-v2v because we also have so much other additional info about the system. So far, 'redhat' pretty much means it uses rpm rather than anything else.
How about instead of "distrofamily" we add flags to tell us what we actually want to know:
uses_rpm uses_dpkg
or, as this would be single-os specific:
package_management=rpm package_management=dpkg
Yep, this looks good to me, though perhaps name it 'package_format', unless you are actually wanting to represent the basic package tool vs format. This packaging stuff is a great example of the trouble of the distro family idea. eg, if you wanted to track the package type, then you'd want fedora + rhel together, since they both use rpm. If you wanted to track package repository service, then you'd want fedora & rhel separate (aka, YUM repo vs RHN). If you wanted to track package mgmt command line tool, then you'd want fedora + rhel5 separate from rhel <= 4, (aka '/usr/bin/yum' vs '/usr/bin/up2date'). So even for the simple task of package mgmt, the 'distrofamily' is insufficiently expressive
My only concern about that scheme is that at this point we have little idea about what we need to know. I guess it won't be too hard to add it as we go along.
I think this is a benefit ! You can trivially add new metadata tags for specific things you discover you need to track, and not have to worry about typing to squash them into an ill-fitting distro-family set. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Fri, Jul 17, 2009 at 12:06:31PM +0100, Matthew Booth wrote:
On 17/07/09 11:21, Daniel P. Berrange wrote:
IMHO doing this is a big mistake. This is what we did for virt-install and hugely regret it. Things just don't fall into a nice hierarchy. We are now looking at doing a flat list of distros + tagging/categorization relationships to be defined.
http://www.redhat.com/archives/et-mgmt-tools/2009-June/msg00018.html
Thanks, Dan.
What problems did you hit? I'm inclined to think I might get away with it for virt-v2v because we also have so much other additional info about the system. So far, 'redhat' pretty much means it uses rpm rather than anything else.
A hierarchy was insufficiently flexible. eg, you can't represent fact that CentOS and RHEL are essentially identical. Can't represent that RHEL-5.3 has VirtIO, but RHEL-5.2 does not. Can't represent the idea of one distro being a newer version of another. THe core problem is that different pieces of information you care about imply different types of hierarchy or relationship, to the extent that you cannot have a single hierarchy that works. The only conclusion I could come to is that hiearchies are fundamentally the wrong approach, and that a flat list of distros + metadata tagging/categorization was what we needed. You can of course later construct arbitrary hierarchies at a UI level from the metadata.
Are you actually doing OS detection, or is this just for filling in distro-specific defaults? What sort of data do you have on individual distros?
We detect the OS type from the install media using a variety of heuristics. eg, looking for $URL/.treeinfo to identify Fedora distros. Once we've determined the distro, we lookup various bits of device info in the OS dictionary such as whether to use virtio, enable ACPI/APIC, whether it can do Xen paravirt CDROM device, the type of mouse to configure, preferred clock sync mode, etc, etc Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (3)
-
Daniel P. Berrange -
Matthew Booth -
Richard W.M. Jones