On Thu, Jul 21, 2011 at 5:08 PM, Rogutės Sparnuotos <rogutes@googlemail.com> wrote:
C Anthony Risinger (2011-07-21 16:42):
... the motivation of this message is to encourage adding some routines to the makepkg library, similar to msg/msg2/warning/etc, to handle development checkouts. basically i see people using _gitroot and _gitname for different stuff ... namely _gitname. i'd like to see a routine that pulls the repo to a known location so it doenst get blown away every update, and so the user doesnt have to manually manage this. everyone does it differently, puts the repository in all sorts of different locations/etc, and it just isnt very pretty IMO. <snip>
I am sure you didn't ask, but I use $SRCDEST/scm for this, do not define sources=() and run this in build(): cp -r "$SRCDEST/scm/$pkgname" "$srcdir/"
nah i didnt ask, but hey no one needs my approval anyway :-) i started off doing it just like that too ... but there are some problems: ) mkchrootpkg sets that variable itself, ie. it's not stable ) ... *anyone* can set it, ie. it's very not stable ) more of a runtime/per-invocation/cache setting vs. a stable/known location ) not overridable from env in mkchrootpkg without patch (use of sudo kills env) also, $SRCDEST is still a "cache" location, like the pacman cache. it's safe to delete. in fact that's what `--cleancache` in makepkg does ... i want to establish a known STABLE location because it's NOT safe to delete repos unless you really really REALLY mean to. additionally, your routine, while it would work for most simple/small packages, would cause a 1GB+ copy and then a massive checkout for my reference PKGBUILD *everytime* i ran makepkg. considering this package take several hours to build on a fairly powerful machine, up to 8+ on a normal machine, i'd prefer if it didn't wipe it out when something failed :-) my routines are specifically designed for maximum reuse and minimum downtime. if everyone used the same routines, we could have *automagic* sharing between competing PKGBUILDs, AND i could reuse those repositories for my own development tinkerings. ... imo development packages should be able to mirror the options of regular packages as close as possible, eg.`--noextract` should build without a sync/checkout, `--nobuild` should sync/checkout without a build, maybe even `--allsource` does a checkout + bundling. C Anthony