X-Original-To: alpine-devel@lists.alpinelinux.org Delivered-To: alpine-devel@lists.alpinelinux.org Received: from mail-ew0-f213.google.com (mail-ew0-f213.google.com [209.85.219.213]) by lists.alpinelinux.org (Postfix) with ESMTP id 97ED51EB587 for ; Mon, 9 Nov 2009 15:21:55 +0000 (UTC) Received: by ewy9 with SMTP id 9so3231552ewy.25 for ; Mon, 09 Nov 2009 07:21:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=AL6MDp3oIWTVL09XnISLBQBluzWeF9Ae7sA0ToafZfc=; b=XWssB/8GN5A/ZQGMRf4FqC5q8X1hsbwJfPTHDOg0cNWt0WeKOSWO97Fz+d45R7OZeX /f5f+ZA8v6rw6A/fDYix1M9RCZmAiDPCXMn7mt8MYPZdBQOmrs6g39LiWuaH8XW8ABzz dDx5gyc8rkR0bd6K0Q5IXk/luYcx0D0ge7wF8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=ttsIUrBR9CINPyVqwjdwayj5RTSMtEe7IAaHVJGDf5ZeKkAUTZsH8tg3gtQ7bJJ+hq xBRug/M8ByO2TfMBYohPjtycnIRDNqGi2w/VgbnHC1shq0qp9NKUwq4lZHt9AJdvkGxL x9uckjRBL4A8uXhRuFsPWRt62otvWsbszLysU= Received: by 10.213.45.144 with SMTP id e16mr9127139ebf.99.1257780115055; Mon, 09 Nov 2009 07:21:55 -0800 (PST) Received: from ?10.65.65.1? (ti211310a081-0085.bb.online.no [85.164.0.85]) by mx.google.com with ESMTPS id 10sm6760891eyz.11.2009.11.09.07.21.53 (version=SSLv3 cipher=RC4-MD5); Mon, 09 Nov 2009 07:21:54 -0800 (PST) Subject: Re: [alpine-devel] RFC: volatile repo/apkbuilds From: Natanael Copa To: jeremy@thomersonfamily.com Cc: alpine-devel@lists.alpinelinux.org In-Reply-To: <6602aeca0911090708k162fa7bfuc9ad582dce12b7b4@mail.gmail.com> References: <1257513717.1929.632.camel@ncopa-desktop.nor.wtbts.net> <6602aeca0911090708k162fa7bfuc9ad582dce12b7b4@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 09 Nov 2009 16:23:03 +0100 Message-ID: <1257780183.30128.25.camel@ncopa-desktop.nor.wtbts.net> X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit 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 > 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 ---