Message-ID: <4A7A913C.4020901@renta.net>
Date: Thu, 06 Aug 2009 18:15:56 +1000
From: Mark Constable <markc@renta.net>
User-Agent: Thunderbird 2.0.0.22 (X11/20090719)
Precedence: list
MIME-Version: 1.0
To: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] mrxvt
References: <4A743D6D.3080100@renta.net> <4A7A8601.40007@iki.fi>
In-Reply-To: <4A7A8601.40007@iki.fi>
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable

Timo Ter=E4s wrote:
>> pkgver=3D0.5.4
>> pkgrel=3D$(date -u +%Y%m%d%H)
>=20
> Generally I think having volatile pkgrel is a bad idea. The whole
> idea of aports git tree is that, you can take the aports git commit
> id or tag, and immediately know which packages it contains. This
> breaks that.

But the predominant usage case would be wanting the latest version
and that is always going to be under "master" in Git and clearly
the latest (lowest in visual sort order) in a binary repo. For the
rare case where older commits need to be researched in Git, and
then to find the associated binary package (if it is still available
somewhere), could be covered by a convention of requiring the date
stamp be embedded in all commit logs.

> (And obviously is broken if you build the same package
> twice within an hour.)

Fairly rare and with Arch I find I simply remove the current cached
binary package and build again with the same timestamp. I have not
tried doing this with Alpine.

Worst case, wait 59 minutes to build the next official version to
be uploaded for public access.

> However, we do need better way to address pkgrel. E.g. we do need
> some way to have svn/git APKBUILDs that automatically just take
> the source head, and produce a package. So I'm wondering if we should:
> 1. have a "volatile" repository with APKBUILDs like this

This could be useful beyond solving this "problem". I modified my
local abuild APKBUILD to pull from git and I had the latest "-d"
modification installed and usable within seconds of seeing the
commit log in my mailbox. There is currently no where for this
possibly quite useful (to some) source package to go for others
to also take advantage of.

> 2. have a script that automatically bumps up the pkgrel's based
>   on what's available (it could even generate it from svn revision
>   or git-describe) and commit it to aports

As I have pointed out, this produces a lot of git log noise when
a few dozen or more packages are updated on a daily basis. It
definitely makes it a lot harder to research what real changes
were actually made to any of this class of package.

> 3. have a "master timestamp" to which all APKBUILDs base their
>   code checkouts. so refreshing the entire system is just changing
>   one file.

Extra complexity to solve a problem that, to me (an Alpine novice),
is not really a problem if the dynamic pkgrel in a volatile repo,
for instance, was acceptable.

--markc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---