Naming issue for meego 1.0 related packages

Chen Lei supercyper1 at gmail.com
Fri Jul 9 16:28:26 UTC 2010


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)

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.

[1]http://meego.gitorious.org/meego-netbook-ux/meego-panel-zones/blobs/master/configure.ac
[2]http://repo.meego.com/MeeGo/builds/trunk/1.0.80.9.20100706.1/netbook/repos/source/meego-panel-zones-0.2.1-2.2.src.rpm
[3]https://fedoraproject.org/wiki/Packaging:SourceURL#Troublesome_URLs

Regards,
Chen Lei



More information about the mobility mailing list