Subject: [alpine-devel] RFC: volatile repo/apkbuilds

From: Natanael Copa <[email-masked]>
Date: Fri, 06 Nov 2009 14:21:57 +0100

Hi,

Been playing with the idea previously mentioned by Mark Constable with
volatile packages from svn/git/cvs.

The idea is that each run it will update the sources from git/svn and if
needed, recompile. That way we could have a "volatile" repository which
tracks some upstream projects, like apk-tools, abuild etc.

This gives us early packages for testing/development.

What would be nice is if:
* packages are only updated/rebuilt when upstream have changes. so 
  pkgrel=$(date -u +%Y%m%d%H) 
wont do it.

* package version includes the scm id of some sort.

* we dont need to modify the apkbuild when things changes upstream

So far I have been thinking in those lines:

Set pkgver to "volatile":
pkgver="volatile"

The must provide a getpkgver() function which will give the pkgrel late.

The apkbuild must override the fetch() and unpack() functions.

Example:

...
source=
_git_source="git://git.alpinelinux.org/apk-tools"

getpkgver() {
        if [ ! -d "$srcdir"/$pkgname ]; then
                unpack
        fi
        cd "$srcdir"/$pkgname
        local tagver=$(git describe --exact-match | sed 's/^v//')
        local n=$(git describe --long | cut -d- -f2)
        pkgver=${_tagver}_git${n}
}

fetch() {
        msg "Fetching source from $_git_source"
        if [ -d "$SRCDEST"/$pkgname/.git ]; then
                cd "$SRCDEST"/$pkgname
                git pull --rebase
        else
                rm -rf "$SRCDEST"/$pkgname
                git clone "$_git_source" "$SRCDEST"/$pkgname
        fi
        cd "$SRCDEST"/$pkgname
}

unpack() {
        if [ ! -d "$SRCDEST"/$pkgname ]; then
                fetch
        fi
        mkdir -p "$srcdir"/$pkgname-$pkgver
        rsync -a --delete "$SRCDEST"/$pkgname/ \
                "$srcdir"/$pkgname
}

build() {
        cd "$srcdir/$pkgname"
        make || return 1
}

package() {
        cd "$srcdir/$pkgname"
        make DESTDIR="$pkgdir" install
}
...

Does that make sense?

Other ideas?

-nc

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

---

From: Jeremy Thomerson <[email-masked]>
Date: Mon, 9 Nov 2009 09:08:14 -0600

Seems to make sense to me.  I have a question, though:  Say there are two
packages I have installed - PackageA from volatile and PackageB version
1.2.2 from main.  If PackageB suddenly shows up in volatile, would my next
update upgrade it?  I think it would be important that only packages that
are already installed as volatile versions are upgraded to other volatile
versions.

Jeremy

On Fri, Nov 6, 2009 at 7:21 AM, Natanael Copa <[email-masked]>wrote:

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

---

From: Natanael Copa <[email-masked]>
Date: Mon, 09 Nov 2009 16:23:03 +0100

On Mon, 2009-11-09 at 09:08 -0600, Jeremy Thomerson wrote:
> Seems to make sense to me.  I have a question, though:  Say there are
> two packages I have installed - PackageA from volatile and PackageB
> version 1.2.2 from main.  If PackageB suddenly shows up in volatile,
> would my next update upgrade it?

yes. well depends on what version you put on it. If you add volatile
repo and apk finds out you have same package in both repos (main and
volatile or anything else for that matter) apk will pick the newest one.

> I think it would be important that only packages that are already
> installed as volatile versions are upgraded to other volatile
> versions.

then you can call your PackageB for PackageB-git with a conflict on
PackageB (so they cannot be installed at the same time)

We actually tried that with ipsec-tools-cvs and it was no good.

but yes, volatile repo is not for everyone and its not for production.

-nc

> Jeremy
> 
> On Fri, Nov 6, 2009 at 7:21 AM, Natanael Copa
> <[email-masked]> wrote:
>         Hi,
>         

---