Mark Constable wrote:
> FWIW> > % cat eth-os/mrxvt/APKBUILD> # Contributor: Mark Constable <markc@renta.net>> # Maintainer: Mark Constable <markc@renta.net>> pkgname=mrxvt> pkgver=0.5.4> pkgrel=$(date -u +%Y%m%d%H)
I think this was already discussed to some degree earlier.
But here's my 2cents.
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. (And obviously is broken if you build the same package
twice within an hour.)
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
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
3. have a "master timestamp" to which all APKBUILDs base their
code checkouts. so refreshing the entire system is just changing
one file.
- Timo
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Mark Constable wrote:
> Timo Teräs wrote:>>> pkgver=0.5.4>>> pkgrel=$(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.> > 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.)> > 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.
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> > 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> > 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.> > 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
---
Mark Constable wrote:
> Timo Teräs wrote:>> The point I had is that: you need a reliable way to get the used>> sources so you can debug the binaries if needed.>> ...>> The problem is that we need a way to reconstruct set of used sources>> in a deterministic way.> > I kind of see what you are getting at but in my limited experience> I have never had the need to do that so please ignore my comments.
It is needed to:
1. make informative bug reports
2. verify if bug is fixed in the specific release (so you can double
check if it's a new bug or not)
3. if you want to debug the application (e.g. when received core)
4. to make the system not depend on system clock; instead it depends
on source id's used
> BTW I hope someone commits a mrxvt package as I use it.
We are currently fixing the urgent issues in 1.9.0-beta1 and hope
to do beta2 today with most stopper problems fixed. I'm sure
ncopa will take a look at it after that.
- Timo
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Sat, 2009-08-01 at 23:04 +1000, Mark Constable wrote:
> FWIW> > % cat eth-os/mrxvt/APKBUILD> # Contributor: Mark Constable <markc@renta.net>> # Maintainer: Mark Constable <markc@renta.net>> pkgname=mrxvt> pkgver=0.5.4> pkgrel=$(date -u +%Y%m%d%H)
unfortunally we cannot have this in "official" alpine releases for
reasons Timo explained.
> pkgdesc="A multi-tabbed X terminal emulator based on rxvt code"> url="http://materm.sourceforge.net/wiki/pmwiki.php"> license="GPL"> depends="libpng libjpeg libxft libxpm"
Should be:
makedepends="libpng-dev jpeg-dev libxft-dev libxpm-dev"
and depends should be empty. Nowdays abuild will detect dynamic linking
libs automatically.
> subpackages="$pkgname-dev $pkgname-doc"> source="> http://downloads.sourceforge.net/sourceforge/materm/$pkgname-$pkgver.tar.gz> mrxvt-0.5.4-002-fix-segfault-when-wd-empty.patch> mrxvt.desktop> "> > # append extra dependencies to -dev subpackage> # remove if not used.> # depends_dev="somepackage-dev"
Since this is an x11 package and oviously have a -dev subpackage, I'd
like to have a look if there is some usr/lib/pkgconfig/*.pc file. The
-dev package migh have some dependencies. If the -dev package have no
dependencies those lines should be removed.
> build()> {> cd "$srcdir"/$pkgname-$pkgver> patch -p0 < ../../mrxvt-0.5.4-002-fix-segfault-when-wd-empty.patch || return 1
use either $srcdir or ../
the fetch() function will create a link from $SRCDEST
> ./configure \> --prefix=/usr \> --sysconfdir=/etc \> --enable-xft \> --enable-text-shadow \> --enable-transparency \> --enable-smart-resize \> --enable-menubar \> --disable-ourstrings \> --enable-linespace \> --enable-256colors \> --enable-xim \> --enable-thai \> --enable-greek \> --enable-cjk \> --enable-backspace-key \> --with-save-lines=2048 || return 1> make || return 1> make DESTDIR=$pkgdir install || return 1> install -Dm644 ../mrxvt.desktop $pkgdir/usr/share/applications/mrxvt.desktop> > # install -m755 -D "$srcdir"/$pkgname.initd "$pkgdir"/etc/init.d/$pkgname> # install -m644 -D "$srcdir"/$pkgname.confd "$pkgdir"/etc/conf.d/$pkgname
those shoudl be removed.
> }> md5sums="0232c8868484751dcb931a28f0756f69 mrxvt-0.5.4.tar.gz> ca3651babc1599a6a8b1be2fee18920d mrxvt-0.5.4-002-fix-segfault-when-wd-empty.patch> 8351fe9189c197b5c61e27ad8d25c062 mrxvt.desktop">
Other than that, looks very good, specially when thinking of that this
is your first APKBUILD and the amount of available documentation.
Will look at it after beta2.
Thanks!
-nc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Timo Teräs wrote:
>> pkgver=0.5.4>> pkgrel=$(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.
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
---
Timo Teräs wrote:
> The point I had is that: you need a reliable way to get the used> sources so you can debug the binaries if needed.> ...> The problem is that we need a way to reconstruct set of used sources> in a deterministic way.
I kind of see what you are getting at but in my limited experience
I have never had the need to do that so please ignore my comments.
BTW I hope someone commits a mrxvt package as I use it.
--markc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Sat, Aug 1, 2009 at 1:04 PM, Mark Constable <markc@renta.net> wrote:
> FWIW>> % cat eth-os/mrxvt/APKBUILD
...
I added the APKBUILD after some cleanups.
Thanks!
--
Natanael Copa