24 Dec
2011
24 Dec
'11
4:48 p.m.
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
24 Dec
24 Dec
5:17 p.m.
New subject: [trinity-devel] Packaging naming with GIT
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?
11 p.m.
New subject: [trinity-devel] Packaging naming with GIT
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?
<snip>
The Debian/Ubuntu builds utilize the revision *count*, that is, the number
of commits that have been made to each module.
You can get this number by using the following (nasty, complex, and
completely unobvious) command:
git shortlog . | grep -E '^[ ]+\w+' | wc -l
SVN was much easier in this regard. ;-)
Tim
11:01 p.m.
New subject: [trinity-devel] Packaging naming with GIT
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?
<snip>
The Debian/Ubuntu builds utilize the revision *count*, that is, the number
of commits that have been made to each module.
You can get this number by using the following (nasty, complex, and
completely unobvious) command:
git shortlog . | grep -E '^[ ]+\w+' | wc -l
SVN was much easier in this regard. ;-)
Tim
11:06 p.m.
New subject: [trinity-devel] Packaging naming with GIT
The
Debian/Ubuntu builds utilize the revision *count*,
that is, the number
of commits that have been made to each module.
You can get this number by using the following (nasty,
complex, and
> completely unobvious) command:
> git shortlog . | grep -E '^[ ]+\w+' | wc -l
>
> SVN was much easier in this regard. ;-)
11:14 p.m.
New subject: [trinity-devel] Packaging naming with GIT
The Debian/Ubuntu builds utilize the revision *count*,
that is, the number
of commits that have been made to each module.
You can get this number by using the following (nasty,
complex, and
> completely unobvious) command:
> git shortlog . | grep -E '^[ ]+\w+' | wc -l
>
> SVN was much easier in this regard. ;-) Should we agree to a relatively common package naming
scheme for all
packagers?
We can try, but I'll play it by ear. :-) I have no desire to change the
Debian scheme, as it might badly break upgrades for Debian/Ubuntu users.
Tim
25 Dec
25 Dec
10 p.m.
New subject: [trinity-devel] Packaging naming with GIT
I use this:
arts-trinity - 4:14.0.0-0debian0+r49+pr4~wheezy
14.0.0 is the TDE version, 0debian0 is Debian specific and
normally
increments on any required rebuilds, r49 is the TDE source
revision of the
arts module, pr4 is the Debian packaging revision of the
arts module, and
~wheezy is the distro version's codename.
I see the release version is three numbers. GIT versions will change daily, but if the
official release number changes does that mean official tarballs will be released too?
Version 14.0.0: new tarballs
Version 14.0.1: new tarballs
Version 14.1.0: new tarballs
Only developers and testers will be concerned with the GIT release numbers?
I'm thinking packagers should avoid using the GIT version in the package name if the
package is built with an official tarball release.
Official tarball releases:
arts-14.0.0-i486-1.txz
arts-14.0.1-i486-1.txz
arts-14.1.0-i486-1.txz
GIT packages:
arts-14.0.0_r2371-i486-1.txz
arts-14.0.1_r2771-i486-1.txz
arts-14.1.0_r3071-i486-1.txz
Users then know that packages with GIT versions are unofficial testing packages and not
official releases.
Sound good?
Darrell
4515
days inactive
4516
days old
6 comments
3 participants
participants (3)
-
Baho Utot -
Darrell Anderson -
Timothy Pearson