Subject: [alpine-devel] [PATCH] Initial APKBUILD for mr

From: Fabian Affolter <[email-masked]>
Date: Sun, 3 Jul 2011 14:35:16 +0000

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 <[email-masked]>
+# 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

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: William Pitcock <[email-masked]>
Date: Sun, 3 Jul 2011 13:20:14 -0500

hi,

> +++ b/testing/mr/APKBUILD

this has been committed.  however, since there is no maintainer field
set, it cannot enter main even though it works fine.

william

---

---

From: Fabian Affolter <[email-masked]>
Date: Sun, 03 Jul 2011 20:43:43 +0200

> set, it cannot enter main even though it works fine.

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.

Fabian

---

---

From: William Pitcock <[email-masked]>
Date: Sun, 3 Jul 2011 14:48:25 -0500

hi,

> in another distribution already.

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

---