Naming issue for meego 1.0 related packages

pbrobinson at pbrobinson at
Fri Jul 9 14:02:18 UTC 2010

On Fri, Jul 9, 2010 at 2:21 PM, Chen Lei <supercyper1 at> wrote:
> 2010/7/9 pbrobinson at <pbrobinson at>:
>> Hi Chen,
>> As I'm the MeeGo maintainer let me outline my thoughts and reasoning
>> behind my MeeGo strategy.
>>> I intend to review two meego-related packages[1][2], but I'm confused
>>> with which package name will be more appropiate.
>>> [1]
>>> [2]
>> All moblin packages will be renamed to meego. Whether that is all
>> during the F-14 timeframe or isn't completed until F-15 I'm not sure
>> yet. All new packages I intend to call meego as I don't see the point
>> in reviewing them now and renaming them in a month or two, possibly
>> less.
>>> The packager is determined to package meego 1.0 packages for F14 which
>>> means we need to package old versions instead of latest upstream
>>> version. Meego 1.0 still use old package name moblin-*  the same as
>>> moblin 2.1 for all of  its packages. Howerver, upstream renamed all of
>>> those package to meego-* in meego 1.1 which will be released in Oct.
>>> 2010.
>> No I'm not determined to package MeeGo 1.0 for F-14. So please don't
>> change what I have said. In the short term I plan to package MeeGo 1.0
>> for the alpha so that there is something for people to start testing
>> with. There's currently very little in the MeeGo 1.1 release and
>> there's a lot of churn due to the renaming upstream which is and will
>> cause us problems. So once F-14 alpha is out and the F-14/rawhide
>> branch has taken place I can then do all the rename breakage in F-15
>> and get the 1.1 package deps shake up stabilized there while people
>> can continue to test some stuff in MeeGo 1.0 in the F-14 branch where
>> its hopefully slightly stable and some of the other things that have
>> changed from Moblin 2.1 to 1.0 have changed and can be closely tested.
>> Once MeeGo 1.1 in F-15 rawhide is OK and looking OK I can then build
>> and tag it quickly and simply into F-14.
>>> I want to ask if it's appropiate to use new package name meego-*
>>> instead of moblin-* for meego 1.0 packages.
>>> e.g.
>>> meego-panel-devices
>>> Upstream uses moblin-panel-devices[3] in meego 1.0, but renamed it to
>>> meego-panel-devices[4] in meego 1.1. If we intend to package version
>>> 0.1.30, then which name will be more appropriate?
>>> [3]
>>> [4]
>>> Note:
>>> It seems upstream will not rename those packages to meego-*  in meego 1.0.
>> No, but that was due to time and QA in the lead up to release. We
>> don't need to follow 100% what they do and I don't see the point in 2
>> package reviews for the one package in less than a month. The upstream
>> git even for the 1.0 release is called meego, its clearly stated in
>> the upstream the direction the package names are going so I don't see
>> what the issue is.
>> Peter
>> --
> Sounds reasonable to me, but the version you packaged actually are
> still moblin-* [1] instead of meego-* regardless of what repo names
> they use, it's unacceptable under most circumstance.

I don't believe it is unacceptable and you didn't read my points above.

> [1]
> %files -f moblin-panel-zones.lang
> %defattr(-,root,root,-)
> %{_libexecdir}/moblin-panel-zones
> %{_datadir}/dbus-1/services/org.moblin.UX.Shell.Panels.zones.service
> %{_datadir}/mutter-moblin/panels/moblin-panel-zones.desktop
> %{_datadir}/moblin-panel-zones/
> Another thing confused me is why you want to use git snapshot instead
> of upstream tarball in src.rpm. It seems like you rely on the git SHA1
> on the particular tags in the meego 1.0 branch, but it's very hard to
> track upstream in this way.

I'm using the tags from git due to the lack of properly URL
referenceable tar file releases as required by the packaging
guidelines. git is actually generally easier to follow and I'm working
with upstream to ensure consistent tagging. Scripts help there.

> e.g. meego-panel-zones
> The latest tag in meego 1.0 branch is 0.1.18[2]  which is also the
> version you choose to package. Howerver, upstream repo version for
> meego 1.0 is 0.1.19[3] which don't have a tag in meego 1.0 branch.
> Things become much worse if we look at meego 1.1, the latest git tag
> is also 0.1.18[4], but upstream repo already update meego-panel-zones
> to 0.2.1[5].

Well 0.1.19 came out just now as part of the 1.0.1 update. 0.1.18 was
part of the 1.0 gold release.

> Historically, moblin released tarballs for its packages in public git
> repo, but memeo and meego don't release tarball publicly. I think we
> have to use tarballs in the src.rpm for meego specfic packages.

Moblin provided auto tar files from git. In later times they added
proper tar releases too. They haven't rules out adding either/or back.


More information about the mobility mailing list