~alpine/devel

2 2

[alpine-devel] RFC: volatile repo/apkbuilds

Details
Message ID
<1257513717.1929.632.camel@ncopa-desktop.nor.wtbts.net>
Sender timestamp
1257513717
DKIM signature
missing
Download raw message
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:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Jeremy Thomerson <jeremy@thomersonfamily.com>
Details
Message ID
<6602aeca0911090708k162fa7bfuc9ad582dce12b7b4@mail.gmail.com>
In-Reply-To
<1257513717.1929.632.camel@ncopa-desktop.nor.wtbts.net> (view parent)
Sender timestamp
1257779294
DKIM signature
missing
Download raw message
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 <natanael.copa@gmail.com>wrote:

> 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:  alpine-devel+unsubscribe@lists.alpinelinux.org<alpine-devel%2Bunsubscribe@lists.alpinelinux.org>
> Help:         alpine-devel+help@lists.alpinelinux.org<alpine-devel%2Bhelp@lists.alpinelinux.org>
> ---
>
>
Details
Message ID
<1257780183.30128.25.camel@ncopa-desktop.nor.wtbts.net>
In-Reply-To
<6602aeca0911090708k162fa7bfuc9ad582dce12b7b4@mail.gmail.com> (view parent)
Sender timestamp
1257780183
DKIM signature
missing
Download raw message
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
> <natanael.copa@gmail.com> wrote:
>         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:  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
---
Reply to thread Export thread (mbox)