24 Dec
2011
24 Dec
'11
5:17 p.m.
On 12/24/2011 11:48 AM, Darrell Anderson wrote:
With SVN I used a package naming scheme based upon the
previous official release number and SVN version:
kdebase-3.5.12-125202-i486-1.txz
With the official tarballs the package name excluded the SVN version:
kdebase-3.5.13-i486-1.txz
I expect to continue that naming scheme with official release tarballs, although the
version numbers change:
kdebase-r14.0-i486-1.txz
Enter GIT.
GIT uses a weird hash number for each patch version. Is there a more straightforward
version number? Or will I have to start naming GIT builds using a date and time scheme?
kdebase-20120101_2200-i486-1.txz
More generally, should we adopt a common package naming scheme, as much as possible
within the limitations of each distro's package naming conventions? Might be nice if
all of us use a somewhat similar naming scheme.
Ideas? Comments?
Darrell
I am working with this also.
What I am thinking I will do is this, which is along the lines you are
considering....
packagename-git-date.tar.xz
example: tdelibs-git-2011-12-24.tar.xz
Then I am going to build like once a week, automated of course.
I will have two scripts the first on will git clone the package(s) and
make a tarball, sed the version numbering in the build script.
The second one will then do the build.
May not workout that way but that is my plan so far.
This is from my build script, tested it works for me.
Well I am testing it now and it seems to be working.....
It will change when I go to git as this one fetchs the 3.5.13 version, I
will remove the pushd git popd so it will give me the master
mksource() {
git clone http://scm.trinitydesktop.org/scm/git/${pkgname}
pushd ${pkgname}
git checkout v3.5.13
popd
tar -cvJf ${pkgname}-${pkgver}.tar.xz ${pkgname}/*
}
Gives me a source tarball like this tdelibs-3.5.13.tar.xz
Maybe that helps?