Naming issue for meego 1.0 related packages

[pbrobinson at gmail.com]

On Fri, Jul 9, 2010 at 5:28 PM, Chen Lei <supercyper1 at gmail.com> wrote:
> 2010/7/9 pbrobinson at gmail.com <pbrobinson at gmail.com>:
>> On Fri, Jul 9, 2010 at 2:21 PM, Chen Lei <supercyper1 at gmail.com> wrote:
>>> 2010/7/9 pbrobinson at gmail.com <pbrobinson at gmail.com>:
>>>> Hi Chen,
>>>>
>>>I don't believe it is unacceptable and you didn't read my points above.
> I said it's unaccptable under most circumstance, considring meego 1.0
> packages is a short life package, I tend to agree with to use new name
> for meego 1.1 directly :). This isn't a serious issue.
>
>>> 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.
>>
>>> 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.
>>
>
> I think it's not easy to persuade upstream to do so. Look deep at
> meego-panel-zones, the HEAD version in git repo is 0.2.0[1], however
> upstream rpm indicates the lastest version for this package is
> 0.2.1[2], maybe they also have a internal VCS because obviously 0.2.1
> is newer than 0.2.0, 0.2.1 fixs some bugs in 0.2.0(e.g. rename
> meego.org to meego.com)

In most cases most of their minor releases are often a single commit.
I'm meeting up with a lot of the NetBook UX guys for beer tonight..
:-) I know they don't have internal VCS and I suspect either there's a
single commit difference or someone forgot to push their local git.
Most of the team are generally very responsive and are all active
contributors to other upstream gnome technology.

> I'm not sure if meego will provide tarballs in the future, the fact I
> found is all memeo and qt packages in gitorious.org don't provide
> tarballs in git repo(a few of them release tarballs in project website
> e.g. qt4, pyside), maybe this is limited by the infrastructure.  Using
> tarballs without valid URL is not forbidden by packaging guideline[3],
> I think using tarballs extracted from upstream SRPM is much easier for
> reviewers when considering md5sum checking in package review. Also,
> the git source is premature, normally we need autoconf/automake to
> build those packages which is not needed for tarballs from SRPM. So I
> suggest you to use tarballs extracted from upstream SRPM, I already
> packaged some qt-related packages for meego 1.1, I found sometimes
> it's very hard to find the exact git SHA1 for a particular upstream
> version.

Yes, but most of the Netbook side of things are from Moblin. Also if
you look at a lot of the clutter/mx and other stuff they now do make
tarballs and in some cases only in the last weeks. Don't rule it out.
After all they cut tar files for the rpms, all they have to do it
publish them separately. In the Moblin case it was just resources that
stopped them originally and they eventually started to do it.

Peter