On Thu, Jul 21, 2011 at 5:08 PM, Rogutės Sparnuotos <rogutes@xxxxxxxxxxxxxx> 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
