Sorry for my intrusion but why don't you use a git clone working dir for the document root of the http server. With that we can change the tree easily, we need only one branch that represent all the versions of the packages that can be download. Also with this the same file in different paths are only download only once.
Yves Le 28 mars 2015 à 12:54, Mega <erich.t...@think.ch> a écrit : > > > Am 27.03.2015 um 19:34 schrieb kp kirchdoerfer: >> Am Freitag, 27. März 2015, 17:54:43 schrieb Erich Titl: >>> Am 27.03.2015 um 16:43 schrieb kp kirchdoerfer: >>>> Am Freitag, 27. März 2015, 16:22:40 schrieb Erich Titl: >>>>> Am 27.03.2015 um 15:53 schrieb kp kirchdoerfer: >>>>>> Am Freitag, 27. März 2015, 09:12:04 schrieb Erich Titl: >>>>> ... >>>>> >>>>>> Yes it's effcient with branches.But it's not really efficient with >>>>>> binaries, though as discussed that's a workaround for the missing >>>>>> ftp/whatever-space. >>>>> >>>>> To git a file is a file is a file and if a file differs it needs to >>>>> somehow record the differences. This is difficult with binary files, as >>>>> you cannot really record the differences, but afaik git does not do that >>>>> anyway. >>>> >>>> Yes. >>>> >>>>>>>> I have not yet written this back to sourceforge, as I would like to >>>>>>>> have >>>>>>>> some feedback on this aproach. >>>>>> >>>>>> Just play with it and let's know about your findings. >>>>>> Esp stable is a playground, but I hope we can shrink the other repos as >>>>>> well later. >>>>> >>>>> We won't unless we delete old versions. We cannot just store differences >>>>> between binaries, that is why we should be restrictive with releases. >>>>> >>>>> If I look at the packages page with releases >>>>> >>>>> 3_1 4_0 4_1 4_2 4_3 5_0 5_1 >>>>> >>>>> then I would think we could easily just keep 4_3 and remove the other >>>>> releases from the master branch, as the tarballs keep the same data >>>>> anyway. >>>> >>>> Ok. >>>> >>>>>>> Would anyone comment on this please. Does anyone have experience with >>>>>>> the html interface of git? >>>>>> >>>>>> Why do you need a html interface? >>>>> >>>>> Because wget needs it for fetching something using https :-( >>>>> That is what the packages page presents. >>>> >>>> AFAIK https is a feature of the git server. >>>> >>>>> I will try to see what happens if I make 'stable' a remote branch. Is it >>>>> typically immediately accessible? >>>> >>>> One has to track the branch, but it will make no difference for http >>>> access. >>>> >>>> We now have three branches - master, 5.1.3 and stable see >>>> >>>> https://sourceforge.net/p/leaf/packages/ci/master/tree/ >>>> >>>> What's the benefit compared to have a stable directory in master? >>> >>> For the moment just 'gut feeling' . >> >> Argument accepted :)) > > Better one, I can play around without disturbing the existing structure :-) > >> >> >>> I believe it is cleaner to manage a branch, but YMMD. >>> I believe to have different branches for 5.1.3/geode and 5.1.3/i486 >>> would be very efficient to store the corresponding binaries, as they >>> would be shared between the branches. >>> >>> I have a small problem detecting the i386 in an installed release. With >>> the above model we could probably drop this directory. >>> >>> Else could we somehow make all parts ot a running release detectable? >>> >>> I can get the release from initrd.version >>> SALT# cat initrd.version >>> 5.1.3 Rev 1 uClibc 0.9.33.2 >>> >>> I can get a specific release from uname >>> SALT# uname -r >>> 3.10.69-geode >> >>> This is confusing as it is a ALIX >>> SALT# uname -m >>> i586 >>> >>> and this is a WRAP >>> SALT# uname -m >>> i586 >> >>> I cannot detect the i386 anywhere and I have no clue how to find rpi or >>> X86_64 in the running release. I could probably map somehow the >>> processor model to those, but that is not really satisfactory. >> >> The upgrade script has "to know" about our choices. > > Yes I know, but the script is just dumb. It needs to be told and I assume the > user is not knowledgeable either. I want to avoid user intervention to a > maximum. Just buy a stupid Access Point and it knows where to get the latest > version and how to install it. In our case this is a little bit more difficult > >> >> i386/x86_64/arm are the supported architectures (make ARCH=x, when running >> config for the kernel) > > Where can I find this in a running environment? We need an agreement where > the info gets included in a running system so it can be retrieved by software. > >> >> i686/geode/i486/bcmrpi/x86_86 are the kernel archs we choose and name in our >> toolchains - e.g naming the kernel for the raspberry pi 3.10.69-bcmrpi has >> been choosed by myself when building armv6 based support for the rpi. > > OK, so > > geode maps to i386 > i486 maps to i386 > i686 maps to i386 > bcmrpi maps to rpi > X86-64 maps to ? > > Is it really true it has to be that incongruent? > >> >> You can distinguish by uname -r, but we have to keep the toolchain, your >> script and the package store in sync. > > Yes, unless we provide this info in a separate version file. > > I suggest also to just write a version number in latest and stable, thaus > avoiding to have separate branches. > > For example if we > > echo 5.1.4-beta2 > latest > > then the script can easily read latest and update the URL > > cheers > > Erich > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > leaf-devel mailing list > leaf-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/leaf-devel ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
