Re: [Xen-devel] [PATCH 4/5] raisin: Change update/release parsing OSes

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 19/10/15 12:26, Stefano Stabellini wrote:
> On Mon, 19 Oct 2015, George Dunlap wrote:
>> On 16/10/15 14:49, Stefano Stabellini wrote:
>>> On Wed, 14 Oct 2015, George Dunlap wrote:
>>>> At the moment, something like 7.1.1503 will be parsed as RELEASE=7.1
>>>> UPDATE=1503.  Change the bash string so that RELEASE=7 UPDATE=1.1503
>>>> in this case.
>>>>
>>>> Also add an example CentOS 7 release string, and add the RELEASE /
>>>> UPDATE parsing to lsb_release as well.
>>>>
>>>> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx>
>>>> ---
>>>>  lib/common-functions.sh | 8 +++++---
>>>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/lib/common-functions.sh b/lib/common-functions.sh
>>>> index a389054..1343dc8 100644
>>>> --- a/lib/common-functions.sh
>>>> +++ b/lib/common-functions.sh
>>>> @@ -103,13 +103,15 @@ function get_distro() {
>>>>          os_VENDOR=`lsb_release -i -s`
>>>>          os_RELEASE=`lsb_release -r -s`
>>>>          os_CODENAME=`lsb_release -c -s`
>>>> -        os_UPDATE=""
>>>> +        os_UPDATE=${os_RELEASE#*.}
>>>> +        os_RELEASE=${os_RELEASE%%.*}
>>>>      elif [[ -r /etc/redhat-release ]]
>>>>      then
>>>>          # Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>>>>          # Red Hat Enterprise Linux Server release 7.0 Beta (Maipo)
>>>>          # CentOS release 5.5 (Final)
>>>>          # CentOS Linux release 6.0 (Final)
>>>> +        # CentOS Linux release 7.1.1503 (Core)
>>>>          # Fedora release 16 (Verne)
>>>>          # XenServer release 6.2.0-70446c (xenenterprise)
>>>>          os_CODENAME=""
>>>> @@ -120,8 +122,8 @@ function get_distro() {
>>>>                  ver=`sed -e 's/^.* \([0-9].*\) (\(.*\)).*$/\1\|\2/' 
>>>> /etc/redhat-release`
>>>>                  os_CODENAME=${ver#*|}
>>>>                  os_RELEASE=${ver%|*}
>>>> -                os_UPDATE=${os_RELEASE##*.}
>>>> -                os_RELEASE=${os_RELEASE%.*}
>>>> +                os_UPDATE=${os_RELEASE#*.}
>>>> +                os_RELEASE=${os_RELEASE%%.*}
>>>>                  break
>>>
>>> This change is OK, but I don't know if this is what we want for the
>>> other case above. I would be tempted to leave the lsb_release case as
>>> is.
>>
>> ?
>>
>> Don't we want the resulting state of "get_distro()" to work the same
>> whether you have lsb_release installed or not?
>>
>> I wrote this patch quite a while ago, but I'm pretty sure that I tested
>> it with the lsb package installed and not installed for C7 (and maybe C6
>> as well) and with this patch I got the same results.
>>
>> (Or to put it a different way: The only reason I even modified the
>> lsb_release section is because I installed the lsb package and got
>> strange results.)
> 
> The problem is that the lsb_release change would affect other distros too.
> For example on Ubuntu, I get
> 
> sstabellini@kaball:~$ lsb_release -r -s
> 12.04
> 
> with the current scheme:
> os_RELEASE=12.04
> os_UPDATE=""
> 
> with the new scheme:
> os_RELEASE=12
> os_UPDATE=04
> 
> I don't think that's what we want: os_RELEASE should be the output of
> lsb_release -r -s, after all -r stands for "release". What do you think?
> 
> 
> But maybe if there are two dots in the release number then you can
> extract the last number and that could be the update.
> For example, if
> 
> sstabellini@kaball:~$ lsb_release -r -s
> 12.04.1
> 
> then I guess it could make sense to set os_RELEASE=12.04 and os_UPDATE=1.
> Similarly for CentOS if lsb_release -r -s returns "7.1.1503", then we
> could set os_RELEASE=7.1 and os_UPDATE=1503. Would that be good enough?

So the reason I wanted os_RELEASE in this case to be "7" or "6" was
because of the package rename issue with iasl|acpica-tools.  But
actually I've solved that using the "aliases" patch now (see 3/5), so in
fact I don't think anyone is using this information anymore.

So maybe I'll just drop this patch for now and we can sort things out
when we actually need it. :-)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel