Fabian Affolter: 1 Initial APKBUILD for mr 1 files changed, 45 insertions(+), 0 deletions(-)
hi, On Sun, Jul 3, 2011 at 1:43 PM, Fabian Affolter <fabian@affolter-engineering.ch> wrote:
Copy & paste the following snippet into your terminal to import this patchset into git:
curl -s https://lists.alpinelinux.org/~alpine/devel/patches/73/mbox | git am -3Learn more about email & git
Package description: The mr command can checkout, update, or perform other actions on a set of repositories as if they were one combined respository. It supports any combination of subversion, git, cvs, mercurial, bzr, darcs, cvs, and fossil repositories, and support for other revision control systems can easily be added. It is extremely configurable via simple shell scripting. Some examples of things it can do include: - Update a repository no more frequently than once every twelve hours. - Run an arbitrary command before committing to a repository. - When updating a git repository, pull from two different upstreams and merge the two together. - Run several repository updates in parallel, greatly speeding up the update process. - Remember actions that failed due to a laptop being offline, so they can be retried when it comes back online. --- testing/mr/APKBUILD | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 45 insertions(+), 0 deletions(-) create mode 100644 testing/mr/APKBUILD diff --git a/testing/mr/APKBUILD b/testing/mr/APKBUILD new file mode 100644 index 0000000..393d13e --- /dev/null +++ b/testing/mr/APKBUILD @@ -0,0 +1,45 @@ +# Contributor: Fabian Affolter <fabian@affolter-engineering.ch> +# Maintainer: +pkgname=mr +pkgver=1.04 +pkgrel=0 +pkgdesc="A multiple repository management tool" +url="http://kitenet.net/~joey/code/mr/" +arch="noarch" +license="GPL2+" +depends="perl" +depends_dev="" +makedepends="" +install="" +subpackages="$pkgname-doc" +source="http://ftp.de.debian.org/debian/pool/main/m/mr/"$pkgname"_"$pkgver".tar.gz" + +_builddir="$srcdir"/$pkgname + +build() { + cd "$_builddir" + make || return 1 +} + +package() { + cd "$_builddir" + install -Dm755 $pkgname "$pkgdir"/usr/bin/$pkgname || return 1 + cd "$_builddir"/lib + for file in git-fake-bare git-svn unison; do + install -Dpm 0644 $file \ + "$pkgdir"/usr/share/$pkgname/$file || return 1 + done +} + +doc() { + cd "$_builddir" + mkdir -p "$subpkgdir"/usr/share/man || return 1 + mv "$_builddir"/*.1 "$subpkgdir"/usr/share/man/ || return 1 + # Sample configuration files + for file in mrconfig mrconfig.complex; do + install -Dpm 0644 $file \ + "$subpkgdir"/usr/share/doc/$pkgname/$file || return 1 + done +} + +md5sums="9ddd9e5b3a90bcb08ac773ddb1cea512 mr_1.04.tar.gz" -- 1.7.4.5
William Pitcock <nenolod@dereferenced.org>this has been committed. however, since there is no maintainer field set, it cannot enter main even though it works fine.Fabian Affolter <fabian@affolter-engineering.ch>Thanks William for your time to give me feedback about my packages. Are the only requirements to get packages into main that it's working, that there is a maintainer and that somebody did a review? If so, I would be happy to be the maintainer because I'm maintaining this package in another distribution already.William Pitcock <nenolod@dereferenced.org>well, we should look at the lifecycle of the main alpine repository (one of the project goals is to allow teams to create their own repositories for specialised packaging topics) and how testing fits into this. first, alpine releases are branched from edge at a specific time each year. to facilitate this, we impose a soft freeze on the edge repositories a few weeks before we do the actual branch. this allows us to get bugs fixed in main before we do the branch, which makes things easier for the stable release maintainers (ncopa@, tdtrask@, and fabled@ are the main people who touch the release trees at this point). i guess, in a way, you can think of edge in the same way that you would think of 'rawhide' in fedora. it is more like rawhide than it is like 'sid' in debian for example, where the next version of the distribution is mathematically set-derived from what is in 'sid'. so, basically, edge is like 'rawhide', and then edge gets branched into alpine-2.3 or whatever, just like 'rawhide' will get branched into fedora 16 at some point. alright, so, when edge is branched, we only take main and non-free sections. testing is deleted in the branching process and the buildservers which build the branched distribution never see testing packages as we do an archive-wide rebuild when the branch occurs in order to ensure that all of the packages are clean. there is usually a few days of fixing APKBUILDs to handle any incomplete transitions that happened in edge (e.g. where we missed a package in the transition, which can happen in large ones) and then the initial version of the distribution release is built and pushed to our internal mirror (nl.alpinelinux.org), which then fans out to the mirrors in the mirror network over a day or so. so then, this means that testing only exists in edge and is not part of any actual release. why would we provide such a repository? well, the reason why is because testing plays a similar role to NetBSD's pkgsrc-wip, or mentors.debian.org. it allows us to push things that are works in progress and users can opt in to test early builds of packages. this brings me to how a package gets from testing to main or non-free. to do that, the package maintainer when she is satisfied that her package is in a finalized state (in other words, it mostly works and there's no showstopper bugs), then she moves it to the appropriate place in the repository and pushes it which causes the package to be rebuilt and included in main or non-free. however, without a package maintainer, a package cannot enter main because nobody has stepped up to maintain the package and make the decision to move it into main. this has a good side effect, that packages without maintainers (thusly packages that are not maintained) do not enter an actually released distribution. this also means, that in some cases, it is possible for a package maintainer who has direct push access to place a package directly in main. well, it is also possible for a package maintainer that does not, if they can get someone to sign off on it. william --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---Fabian --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---william --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---
--- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---
William Pitcock <nenolod@dereferenced.org>hi, On Sun, Jul 3, 2011 at 9:35 AM, Fabian Affolter <fabian@affolter-engineering.ch> wrote: