X-Original-To: alpine-devel@lists.alpinelinux.org
Delivered-To: alpine-devel@lists.alpinelinux.org
Received: from smtp181.iad.emailsrvr.com (smtp181.iad.emailsrvr.com [207.97.245.181])
	by lists.alpinelinux.org (Postfix) with ESMTP id 474131EBFFE
	for <alpine-devel@lists.alpinelinux.org>; Sat,  8 Jan 2011 02:47:39 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by smtp48.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 8E65D16857A;
	Fri,  7 Jan 2011 21:47:38 -0500 (EST)
X-Virus-Scanned: OK
Received: from dynamic12.wm-web.iad.mlsrvr.com (dynamic12.wm-web.iad1a.rsapps.net [192.168.2.219])
	by smtp48.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 79A9816826F;
	Fri,  7 Jan 2011 21:47:38 -0500 (EST)
Received: from darkregion.net (localhost [127.0.0.1])
	by dynamic12.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 63B802168082;
	Fri,  7 Jan 2011 21:47:38 -0500 (EST)
Received: by apps.rackspace.com
    (Authenticated sender: mcs@darkregion.net, from: mcs@darkregion.net) 
    with HTTP; Fri, 7 Jan 2011 20:47:38 -0600 (CST)
Date: Fri, 7 Jan 2011 20:47:38 -0600 (CST)
Subject: Re: [alpine-devel] Managing source packages
From: "Matt Smith" <mcs@darkregion.net>
To: "Natanael Copa" <ncopa@alpinelinux.org>
Cc: alpine-devel@lists.alpinelinux.org
X-Mailinglist: alpine-devel
Precedence: list
List-Id: Alpine Development <alpine-devel.lists.alpinelinux.org>
List-Unsubscribe: 
	<mailto:alpine-devel+unsubscribe@lists.alpinelinux.org?subject=unsubscribe>
List-Post: <mailto:alpine-devel@lists.alpinelinux.org>
List-Help: <mailto:alpine-devel+help@lists.alpinelinux.org?subject=help>
List-Subscribe: 
	<mailto:alpine-devel+subscribe@lists.alpinelinux.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
In-Reply-To: <20110103142059.5bff7030@ncopa-desktop.nor.wtbts.net>
References: <20101229111233.00776ec7@ncopa-desktop.nor.wtbts.net> 
 <60E8FCA5-7D2E-453A-834D-91129FC0E53F@gmail.com> 
 <1293939379.793825469@192.168.2.227> 
 <20110103142059.5bff7030@ncopa-desktop.nor.wtbts.net>
Message-ID: <1294454858.407214722@192.168.2.227>
X-Mailer: webmail8

On Monday, January 3, 2011 7:20am, "Natanael Copa" <ncopa@alpinelinux.org>=
=0Asaid:=0A=0A> On Sat, 1 Jan 2011 21:36:19 -0600 (CST)=0A> "Matt Smith" <m=
cs@darkregion.net> wrote:=0A> =0A>> I want to point out the potential for f=
ilename clashes, especially=0A>> with patch files, etc., all going into one=
 directory like that.=0A> =0A> I dont think that is a big deal. It is only =
the http:// and ftp://=0A> files we keep in distfiles. The patches are kept=
 in git.=0A=0AAh, good point.=0A=0A>>  It=0A>> might be better to have the =
distfiles be saved to=0A>> $distfiles_dir/$package/<package files>.=0A> =0A=
> This might actually be a good idea anyways. It will avoid one directory=
=0A> with tons of files (check how long time it takes to open=0A> http://di=
stfiles.gentoo.org/distfiles and you'll see whta I mean)=0A> =0A> It will a=
lso make cleaning maintenence easier since it will be clear=0A> what apkbui=
ld that pulled in that particular source.=0A> =0A> The downside is that apo=
rts cannot share source package so things like=0A> linuk kernel source will=
 be downloaded * N times (where N is number of=0A> flavours). Same with for=
 example poppler.=0A=0AWe could eliminate the need to download common sourc=
e files more than=0Aonce by implementing a method to grab the md5sums from =
all APKBUILDs,=0Achecking which md5sum lines are identical and occur atleas=
t twice or more.=0A=0AThe determined common source files would then be move=
d/copied to a=0A'common_files' directory.  Then when abuild searches for th=
e file=0Aunder the package's directory and doesn't find it, have it also=0A=
search the 'common_files' directory.=0A =0A> One thing I thought was that w=
e could create snapshot dirs for=0A> each git tag (v1.10.0, v1.10.1 -> v2.1=
.x) where we create=0A> hardlinks to the distfiles dir. So then you can jus=
t delete all files=0A> in distfiles that are not referenced to in current g=
it master. The=0A> hardlink in snapshot dir will make sure its kept as long=
 as needed.=0A> =0A> If you would like to rebuild v1.10.x you could just ch=
eckout that git=0A> tag, point your DISTFILES_MIRROR to that specific dir a=
nd you had=0A> everythin you needed for rebuilding it.=0A=0ASounds good to =
me.=0A=0A..snip..=0A>> Aside from that, what we if did like Ubuntu and had =
Long-Term Support=0A>> (LTS) releases, where bug-fixes are backported and=
=0A>> distfiles+APKBUILDs are kept for the life of the release (1+ years,=
=0A>> for instance).  Then keep the dist-files+APKBUILDs for the previous=
=0A>> two releases; the next release, be it an LTS release or not, would=0A=
>> mark the End-of-Life (EOL) for the oldest release still kept.=0A> =0A> I=
 have got requests for this before and I do think its a good idea.=0A> The =
problem is that it would require someone to actually take the=0A> responsab=
ility do the job. I don't have capacity for that.=0A> =0A> That said, I try=
 maintain older releases as good as possible and I will=0A> backport fixes =
fro 1.10 (and even 1.9) on request.=0A=0AYeah, that's fair enough.  Unfortu=
nately, I'm not looking to take on such=0Aa task at this time, either.  Unl=
ess, of course, we formed a small team=0Ato take care of it.  Then I'd be w=
illing to take a crack at it.=0A=0AAnyone else?=0A=0A>> So at any time, we'=
re supporting one LTS release and 2 update=0A>> releases.=0A>>=0A>> Somethi=
ng like that anyway.=0A> =0A> I like it. Anyone willing to do the real job =
backporting bugfixes?=0A> Actually, only keeping an eye on the changes and =
decide what should be=0A> backported would be helpful. We could start with =
bugfixes only.=0A=0AYes, bug fixes would be a good start.=0A=0A>> At any ra=
te, I think it'd be a good idea to keep older=0A>> distfiles+APKBUILDs arou=
nd for a little while, so in case someone=0A>> should need to downgrade a p=
ackage, they atleast have the option in=0A>> one form or another.  Perhaps =
even keeping the APKs.=0A> =0A> Yes. We could create source packages (with =
'abuild srcpkg') for=0A> archival purposes. But this won't be very useful w=
hen rebuilding from=0A> scratch, which was Andrew's initial frustration.=0A=
=0AI thought I might double-check and ask: Wouldn't the distfiles server wo=
rk=0Afor source packages too?=0A=0A>> Unfortunately, that will eat up a goo=
d bit of disk space, I presume.=0A>> And although source packages sound lik=
e a good idea, people using=0A>> embedded systems or otherwise wouldn't nec=
essarily have the=0A>> alpine-sdk installed.=0A> =0A> Yeah. tradeoffs...=0A=
=0AWhat do you think about keeping say, the last 5 versions of the APK=0Awi=
th the latest pkgrel (ie, package 1.20-1.24, and say all versions=0Awere at=
 pkgrel 0, except one: 1.20-r0, 1.21-r2, 1.22-r0, etc)?=0A=0AThen implement=
 a way to downgrade to a previously available version=0Athrough apk-tools. =
 (ie, $ apk del php; apk add php-5.3.3, without=0Aadding the pkgrel - unles=
s that becomes a wanted feature later on.)=0A=0AWe could then implement a '=
downgrade' command to apk-tools to achieve=0Athe same thing in one command:=
 $ apk downgrade php-5.3.3=0A=0AAlso, on a side note, I think we should imp=
lement some sort of 'hold'=0Afeature or sub-command to apk-tools, in order =
to keep a package at=0Ait's current version.  This would certainly aid some=
 users of edge,=0Abut might also be used by others who are not following ed=
ge.=0A=0AMatt



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---