Am Montag, 2. März 2015, 15:44:01 schrieb Erich Titl: > Am 02.03.2015 um 14:13 schrieb kp kirchdoerfer: > > Hi Erich; > > ... > > >> Sure, and it might be possible to rearrange the links, so they would be > >> more simple. For example the GIT hash does not help here at all. > > > > It's the download link. No need to rearrange and it's avoided cause it > > will > > break... > > Yes, but close to imposssible to anticipate, so useless for an automaton. > > > ... > > > Indeed. I can't compare - currently the kernel is not part of the donwload > > page... > > Does not make a difference the simplicity is the goal. > > > ... > > >> That is fine, I don't doubt this, just that parsing all this information > >> is not easy. I don't want to have a requirement of a parsing language. > > > > Ok. > > > >>> How do you fetch your packages from leaf.think.ch? > >>> And how can we make shure to work with dependencies with a flat repo as > >>> leaf.think.ch? > >> > >> I don't, because I don't need to. Upgrade does just this, upgrade. It > >> takes the information of a currently working system and tries its best > >> to lift it to an actual version. What i > > > > Ok, I understand, that you are thinking about full-distro-upgrade and > > don't > > bother with packages updates. Even the first one would be a nice > > improvement. > Package updates are difficult unless we have a nicely defined dependency > which is deterministic. If we have that, then this is not a problem. > > >>> Just to be clear - I don't want to push neither git nor the packages > >>> page, > >>> just looking for a working solution, which will not raise maintenance > >>> work. > >> > >> Oh, the current page is deceivingly dumb. It is just an unpacked tarball > >> and it is only necessary because the tarball would be too big and would > >> require too much processing to run it to the target system. It is so > >> much faster to fetch a file from a file system than unpacking it from an > >> archive. > > > > I think it won't be possible to fetch from a tarball - for most of the > > devices it won't be possible to keep even tarball in RAM not to mention > > the unpacked one. > > Right > > > So if you don't want to deal with dependencies, > > Oh I would if I saw a reasonable way, this is just a first attempt. > > revision, incremental updates > > There are hardly any incremental updates in this software, but we can > fine tune the mechanism once it has proven sufficiently stable. > > > etc, there is one remaining pb- I'm not aware of any place in the net, > > where we can store the unpacked tarballs other than a git repo - either > > SF, github, or...., at least not without putting more responsibilty to an > > individual maintaning our own server. > > It should be possible to generate links in a page besides the git repo. > > > We do have two choices: Searching for a file area (you may even ask on SF > > if that is possible (we currently use GB's of disk space... and I'm > > afraid they won't be too happy)) - or you may rethink your decision not > > to deal with a git repo. Maybe we do have a third option I forgot... > > I don't know how git populates the tree, looking at the link you gave me > > https://sourceforge.net/p/leaf/packages/ci/786d2c9d66decc4c2d8409362f1180d94 > 46f0271/tree/5_1/i386/accel.lrp?format=raw > > To me the levels look like > > https protocol / static > sourceforge.net FQDN / static > p/leaf/packages -> some kind of path / static > ci --- no bloody idea / static ? > > 786d2c9d66decc4c2d8409362f1180d9446f0271 --- possibly a GIT hash this > may be problematic > > tree > 5_1 looks like a release / variable > i368 looks like an architecture / variable > accel.lrp package / variable > format well they have a cgi / static > > There is not much information in this URL, we have the package name, the > architecture and the release as variables, for update release could be > either stable or latest, whatever one prefers. The unsightly hash is the > one we need to circumvent. > > For dependencies we can easily use the deplrp files. Extracting, sorting > and unifying the package names and adding them to the list of packages > is a rather easy job, will have a look.
The page I got the URL from is generated from a parser. Will it be any help if we add one or more flatfiles with the architecture, packages and links to git repo? The version could be determined by the SF Files Area e.g. 5.1.3 (https://sourceforge.net/projects/leaf/files/Bering-uClibc/) We may one file for all architecures with the content filename 5.1.3 x86 packagename link-to-git-repo x86 anotherpackage link-to-git-repo rpi or files for each architecture/flavour x86-5.1.3 geode-5.1.3 We may also have something like files for stable and beta in a seperate directory in SF Files area. Adding a few kb to the FRS won't be a problem. just an idea... kp ------------------------------------------------------------------------------ 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
