DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=qRPDyiDRzp5ONslxiwJpjbTUFtFV+TtxMT0X1DE5TVdJ5NeTau20mMP3ZMfBTjRX9Y
         rCwK5XT95fy5/fUPkd8Z2M4Wpj9gN/OIFtTlR3S0UJEwPlBs2LoatXwLnDHtLXgNv0AW
         Qg0to//5lPEwfI/QnOZclAS3OxR7TQ74BsZyU=
Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= <timo.teras@gmail.com>
Message-ID: <4A7A961D.1090701@iki.fi>
Date: Thu, 06 Aug 2009 11:36:45 +0300
From: =?ISO-8859-1?Q?Timo_Ter=E4s?= <timo.teras@iki.fi>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
Precedence: list
MIME-Version: 1.0
To: Mark Constable <markc@renta.net>
CC: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] mrxvt
References: <4A743D6D.3080100@renta.net> <4A7A8601.40007@iki.fi> <4A7A913C.4020901@renta.net>
In-Reply-To: <4A7A913C.4020901@renta.net>
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable

Mark Constable wrote:
> Timo Ter=E4s wrote:
>>> pkgver=3D0.5.4
>>> pkgrel=3D$(date -u +%Y%m%d%H)
>>
>> 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.
>=20
> 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.

The point I had is that: you need a reliable way to get the used
sources so you can debug the binaries if needed.

This is broken: if you do "git checkout <tag|commitid>" and rebuild,
you get still the git/svn head and not the one used to build the
package in first place. You can deduce some of that info from the
dynamic -r, but it's still not accurate enough.

>> (And obviously is broken if you build the same package
>> twice within an hour.)
>=20
> 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.
>=20
> Worst case, wait 59 minutes to build the next official version to
> be uploaded for public access.

Yes, it's not a major issue for upload. But issue for figuring out
which sources were used to build.

>> 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
>=20
> 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.

I'm ok to have "volatile". But then each package version should
be constructed from the svn or git commit id (those are more
reliable than timestamp). Timestamp might be ok for CVS though
(though then the cvs checkout needs to specify the date). The
reason is that system clock might not be right.

And I think this would entitle a new field in the version number.
So we can actually first identify APKBUILD version from -r and
then figure out the code checkout version from some other part.

And we'd need a way for abuild to have "recover sources for
this binary apk using this volatile APKBUILD".

>> 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
>=20
> 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.

Yes. That's the down side.

>> 3. have a "master timestamp" to which all APKBUILDs base their
>>   code checkouts. so refreshing the entire system is just changing
>>   one file.
>=20
> 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.

The problem is that we need a way to reconstruct set of used sources
in a deterministic way.

- Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---