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

Chanho Park chanho61.park at samsung.com
Thu Aug 7 13:05:49 GMT 2014


Hi,

> -----Original Message-----
> From: Chanho Park [mailto:chanho61.park at samsung.com]
> Sent: Thursday, August 07, 2014 9:51 PM
> To: 'Stéphane Desneux'; 'Dev at lists.tizen.org'
> Cc: 'Yury Usishchev'
> Subject: RE: [Dev] Tizen RPM macros now defines %suse_version : good or
> not ?
> 
> 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

+icecream

I missed the icecream. So, I added it into the group tag.

Best Regards,
Chanho Park



More information about the Dev mailing list