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

Tobias Klaus tk+ff at meskal.net
Mo Jan 9 23:10:40 CET 2017


Hey,

auch wenn ich dir Recht geben muss, dass es etwas inkonsistent ist die Repos 
zu löschen und die Downloads nicht, bin ich trotzdem dagegen das src/dl zu 
löschen.

Dass man mal im openwrt arbeitet und den Überblick verlieert sehe ich ja ein, 
aber an den Paket-tarballs patchen ist schon recht ungewöhnlich. Dafür würde 
ich ungern standardmäßig alle Pakete wegwerfen.

Andere Projekte unterscheiden hier auch unterschiedliche "clean"-Arten. 
Vielleicht sollten wir auch zwischen "clean" und "distclean" unterscheiden. 
Ersteres würde nur versuchen die Repos sauber zu kriegen und $target leer 
machen, würde also versuchen Traffic und Zeit zu sparen und zweiteres würde 
dann wirklich den "Auslieferungszustand" wieder herstellen.

Viele Grüße
Tobias

Am Samstag, 7. Januar 2017, 14:59:48 CET schrieb Jan Kraus:
> 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




Mehr Informationen über die Mailingliste franken-dev