[Dev] Tizen RPM macros now defines %suse_version : good or not ?

Chanho Park chanho61.park at samsung.com
Thu Aug 7 12:51:26 GMT 2014


Hi Stephane,

> -----Original Message-----
> From: Stéphane Desneux [mailto:stephane.desneux at open.eurogiciel.org]
> Sent: Thursday, August 07, 2014 9:32 PM
> To: Chanho Park; Dev at lists.tizen.org
> Cc: 'Yury Usishchev'
> Subject: Re: [Dev] Tizen RPM macros now defines %suse_version : good or
> not ?
> 
> On 07/08/2014 13:05, Chanho Park wrote:
> > Hi Stephane,
> >
> >> -----Original Message-----
> >> From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Stephane
> >> Desneux
> >> Sent: Thursday, August 07, 2014 7:09 PM
> >> To: Dev at lists.tizen.org
> >> Subject: [Dev] Tizen RPM macros now defines %suse_version : good or
> not ?
> >>
> >> Hi all,
> >>
> >> Recently, Yury Usishchev added a patch over the rpm package:
> >> https://review.tizen.org/gerrit/#/c/25292/
> >>
> >> This patch adds the %suse_version definition to rpm-tizen_macros.
> >>
> >> This broke the build for some packages that use %suse_version in
> >> Tizen:Common and I opened a bug for that:
> >> https://bugs.tizen.org/jira/browse/TC-1474
> >>
> >> I see two cases:
> >> - a package must be built into Tizen and into openSuse. Example: mic,
> >> kickstarter, ... and maybe other tools that have a single spec file
> for
> >> multiple distros (including tizen)
> >
> > We didn't catch there is some packages to build by openSUSE.
> >
> >> - a package is specific to Tizen but the spec file was initially
> copied
> >> from openSUSE (and may contain some tests on %suse_version which
> should
> >> be removed).
> >>
> >> From what Yury told me, the base reason to add %suse_version was:
> >> "%suse_version macro is checked by 'build' script and enables
> cumulate
> >> install. It is believed to be a bit faster and reduces number of
> errors
> >> with msm.so." So it was added for good reasons. But maybe it's not
> the
> >> proper way to fix the base problem.
> >>
> >>
> >> So my final question is simple: is it desirable to
> define %suse_version
> >> into Tizen ?
> >>
> >>
> >> IMO, the answer should be *no* and we should rollback to the previous
> >> state for all impacted packages (rpm, icecream, mic, kickstarter,
> >> python-yaml, ...). But this also means that the special ops done by
> >> 'build' when it detects the %suse_version macro should be done also
> when
> >> %tizen_version is defined. Is it something that the Tools team can
> >> investigate ?
> >
> > I've made a patch to fix this problem. Instead of defining the
> suse_version,
> > I set the DO_CUMULATIVE varables always TRUE because we'll always use
> newer
> > suse version than 1220.
> > If the patch can resolve the issue, I'll revert all of my patches.
> >
> > https://review.tizen.org/gerrit/#/c/25635/
> 
> LGTM !
> 
> As soon as it's merged, please resubmit the previous group of packages
> in one single group (gbs submit -T <tag>) for:
> - rpm (to be fixed to remove %suse_version in macros)
> - build
> 
> IIRC, the following packages should also be resubmitted in the same
> group with the previously accepted commits:
> - icecream
> - mic
> - kickstarter
> - python-yaml
> - zypper
> 
> I'm not sure if this list is complete, but it's not far from the
> submissions you did to fix the build errors.

I reverted all of the commits and requested them with group tag.

Group tag : submit/tizen/20140807.124405
Packages:
python-pygments
mic
python-yaml
kickstarter
zipper
build

Best Regards,
Chanho Park



More information about the Dev mailing list