HI Erich; Am Montag, 9. März 2015, 11:40:09 schrieb Erich Titl: > Hi KP > > Am 07.03.2015 um 00:34 schrieb kp kirchdoerfer: > > HI Erich; > > > > I'll try to give it a test, but I have to prepare a machine with 5.0 to > > upgarde. Do you really have geode arch? I haven't seen one at a first > > glance. > Indeed, the premissions on the directory were a bit restrictive :-( > > > But your results sounds awesome; good work, we should find a solution! > > > > Am Freitag, 6. März 2015, 14:25:03 schrieb Erich Titl: > >> Hi Folks > >> > >> I have finished the upgrade function, please consider testing it. > >> > >> It uses my small web server on leaf.think.ch which has a 5.1.3 for the > >> following architectures. > >> > >> i486 i686 geode > >> > >> You can get a config.lrp with upgrade included at > >> > >> http://leaf.think.ch/stable/i486/config.lrp > >> > >> I intend to adapt it to sourceforge as soon as I get a reasonably simple > >> URL schema. > > > > I thought a bit further, hopefully not too wrong... > > > > Why don't you just create a git repo in Packages for "stable", with the > > same tree as leaf.think.ch/stable > > and fetch with wget like that > > Because I don't know how to create a repo and/or symlinks at sourceforge.
Don't know about symlinks, maybe Yves can help. But thats how I'd do it; clone the packages repository: git clone ssh://yoursfusern...@git.code.sf.net/p/leaf/packages leaf-packages Note it's huge (approx 2GB and takes a while (we may need to think about shrinking it...) Then follow the tips here: http://bering-uclibc.zetam.org/wiki/Bering-uClibc_5.x_-_Developer_Guide_-_Hints_and_Tips_for_using_Git_SCM#Remote_Branches > > https://sourceforge.net/p/leaf/packages/ci/master/tree/stable/i686/package > > .lrp?format=raw > Mhhh... why should master be in that URL. There is no magic in neither > packages, master, ci nor tree. I would like to see something like > > schema://sourceforge.net/?/leaf/stable > > If git enforces such a naming scheme it suld be easy to get raund it > using symbolic links. Maybe, anyway it would be a start to get tests going... > > Later this should contain a stable version like 5.1.2, 5.1.3, 5.2... > > > > And if possible a git repo "latest" where you can fetch with > > > > https://sourceforge.net/p/leaf/packages/ci/master/tree/latest/i686/package > > .lrp?format=raw > > > > we can use this for testing/playing and later beta versions may live > > there. > > Sure, right now upgrade is geared towards 'stable', as I believe that is > what the end user wants. Yes, but during testing I can the source to point to latest and to play with that without disturbing stable. > > Note https://sourceforge.net/p/leaf/packages/ci/master/tree/stable is the > > fixed part AFAIK, the arch and package name is no different from current > > code, "?format=raw" needs to added to your code. > > Ugly, but what the hell > For the https part, to avoid problems I suggest to drop wget.lrp and > rename wget-ssl.lrp. The difference in size of the two packages does > IMHO not warrant to have both. We don't need https, but we can also remove wget and have wget-ssl as default. But either way we to install a wget package with leaf or by instruction. > > Later(!) we/you could also make use of tags e.g: > > stable/master will have 5.1.4 stable - user can upgrde from 5.1.3 to > > master/5.1.4 > > Why is this necessary? Is it not sufficient to just upgrade to stable > which inherently would be 5.1.4? > > > stable/5.1.3, the previous master, and users can still upgrade from 5.1.2 > > if needed before upgrading to 5.1.4. Might be useful some time. > > Let's not fool ourselves, as nice as versatility may be, the end user > wants somthing simple, e.g. he does not really want a choice, he wants a > product. We don't need to use it as long as we don't need it. > For the sophisticated user there is absolutely no need for upgrade, as > he can mix and match the whole day long. I wanted to keep upgrade > simple, because I myself am too lazy to upgrade. I hope users can be > encouraged to upgrade their LEAF based systems often and without sorrow. > > One thing we need to be aware of if this should catch, we need to make > sure the packages perform as before. One problem I see and used to be > involved in is ipsec. Unfortunately this was called ipsec.lrp (not > openswan.lrp or freeswan.lrp) in the past and the project (openswan) is > in a lamentable state. We need to document these problems in a prominent > place, maybe even issue warnings before upgrading. Maybe we could add an > incompatibility page somewhere. I know this involves a _lot_ of testing. 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
