[PATCH 1/2] added removal of /src/dl to clean function of buildscript

Jan Kraus mayosemmel at googlemail.com
Sa Jan 7 14:59:48 CET 2017


Hi Tim,

Am Freitag, den 06.01.2017, 11:21 +0100 schrieb Tim Niemeyer:
> Am Freitag, den 06.01.2017, 11:05 +0100 schrieb mayosemmel:
> > Hi Tim,
> > 
> > Ich hatte in dem download Ordner rumgepatcht und nach einem "clean"
> > war es immer noch gepatcht.
> Wie das? Die Downloads sind doch mit einer Prüfsumme gesichert?
Die Prüfsummen werden anscheinend nur direkt nach dem Download geprüft.

> > Das hat mich einiges an Zeit gekostet, den Fehler zu finden.
> Verstehe ich.. Normalerweise fummelt man ja auch nicht an den Downloads
> rum. ;)
Naja, beim basteln vllt. doch...
> 
> > Es ist eine gute Sache den Traffic zu sparen wenn ich einen regulären
> > build mache.
> > Wenn ich allerdings eine saubere Build Umgebung brauche und deshalb
> > einen clean mache, sollte der auch alles bereinigen.
> Ne, es ist ja nur ein lokaler Download Cache. Ich sehe das Zeug unter
> dl/ nicht als generierte Daten an. Daher auch kein Clean.
Da muss ich dir etwas widersprechen. Bei einem clean werden auch alle
git repos gelöscht( kernel, openwrt usw.). Es müsste nun entweder so
sein, das diese auch erhalten bleiben oder der dl Ordner auch
mitgelöscht wird.
Ich sehe das clean so, das ich danach garantiert eine saubere Umgebung
habe. Das ist aktuell leider nicht der Fall.
> 
> Um das Verhalten eines Download-Caches zu behalten, müssten wir das
> irgendwie konfigurierbar machen. Es könnte so laufen, dass der User das
> aktiviert und die Daten werden dann irgendwo unter ~/.cache/
> gespeichert. Beim build werden die Daten dann aus dem Cache geladen bzw
> aus dem Netz, wenn im Cache nicht vorhanden. Beim clean werden die Daten
> nahe beim Repo gelöscht, der Cache bleibt erhalten.
Wenn wir das so haben wollen, müssten die repos, die aktuell nach src
geladen werden, ebenfalls da rein wandern. Aktuell ist es halt
inkonsistent.
> 
> Ich weiß nicht, ob der Aufwand gerechtfertigt ist, nur weil du grad mal
> im dl Folder rumgefrimmelt hast.. :P
Wie oben schon geschrieben, haben wir aktuell einen inkonsistenten
Status. Das würde ich gern beheben. Ob es nun aber den Aufwand wert ist,
statt eines einfachen "rm" gleich ein Cache-System zu bauen...

Grüße Jan 
> 
> Tim
> 
> > Grüße Jan 
> > 
> > Am 6. Januar 2017 09:55:56 MEZ schrieb Tim Niemeyer <tim at tn-x.org>:
> > >Moin Jan
> > >
> > >Am Donnerstag, den 24.11.2016, 23:51 +0100 schrieb Jan Kraus:
> > >> Signed-off-by: Jan Kraus <mayosemmel at gmail.com>
> > >> ---
> > >>  buildscript | 2 +-
> > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >> 
> > >> diff --git a/buildscript b/buildscript
> > >> index 25cf291..7d89fbb 100755
> > >> --- a/buildscript
> > >> +++ b/buildscript
> > >> @@ -318,7 +318,7 @@ buildrelease() {
> > >>  }
> > >>  
> > >>  clean() {
> > >> -    /bin/rm -rf bin $builddir src/openwrt
> > >> +    /bin/rm -rf bin $builddir src/openwrt src/dl
> > >Was ist der Grund, warum du das entfernen willst?
> > >
> > >Letztlich scheint es eine gute Sache zu sein den Traffic zu sparen.
> > >
> > >Tim
> 
> -- 
> franken-dev mailing list
> franken-dev at freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 473 bytes
Beschreibung: This is a digitally signed message part
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20170107/4ce678cf/attachment.sig>


Mehr Informationen über die Mailingliste franken-dev