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/786d2c9d66decc4c2d8409362f1180d9446f0271/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. cheers ET
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ 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
