Am 30.03.2015 um 18:39 schrieb Andrew: > 30.03.2015 18:23, Erich Titl пишет: >> Am 30.03.2015 um 17:03 schrieb Andrew: ... >> >> Correct, you cannot just add hardware without adding modules. As there >> is no space on the target machine to hold modules.tgz this is not >> relevant. Lots of our systems are single board computers and there is >> not that much hardware to be added. With the new set up you can fetch >> individual modules from sourceforge, which you could not in the past. > And lots of systems aren't hardware-limited, so maybe we should leave > modules.tgz updating possibility?
No problem on my side, recreating the tarball is a piece of cake. >> >> ... >>>> have a way improving the dependencies, be my guest. >>> Nope, we have deps into /lib/modules/<kernel>/modules.dep. And we have a >>> script that searches for dependencies for list of modules (currently >>> it's used for generating moddb/initmod from module list). >> Those deps files are build at machine boot, not before. >> >> ... > Those deps are also built on build system. You can find modules.dep in > staging/<arch>/lib/modules/<target> dir. So where does this lead us? There is no deps file in modules-xxx.tgz. I must admit, there are lib/module.xxx files in moddb.lrp and I could use them. >>>>> Why we can't use git tags for this? >>>> Maybe we can use git tags. I have not tested this. branches are more >>>> convenient at development stage. >>> We may ad tags x.x-stable and x.x-development. That is fine, I just used a branch as I can easily leave everything as is, and you cannot do that with tags. >> If you can show me the functionality, be my guest. > Tag points to commit. It can be accessed by web like git branch or > commit (https://sourceforge.net/p/leaf/packages/ci/<tag>/tree/).You can > check it on source repo: > https://sourceforge.net/p/leaf/bering-uclibc/ci/5.0.1-beta1/tree/ Yes, but currently these trees do not provide the necessary functionality. > > Currently we push packages, for ex., to 5_0 and 5_1 (and in future to > 5_2) dirs, and for each 'stable' release (for ex., 5.1.3) we haven't > sub-releases that may be done later than next 'development' release (for > ex., we didn't provide 5.1.3.1 after 5.1.4-rc1). So we need just > add/update tags '5.1-stable' and '5.1-development' at each commit (if we > committed 'stable' release - add '5.1-stable' and '5.1-development' tag > to this commit ensure that 'development' users uses most recent version; > if we committed 'development' release - just add/update > '5.1-development' tag). And of course also add tags with releases (like > in source repo). Some of these are unaccessible to upgrade right now. The current tree mechanism is not well suited to auto detecting dependencies and I don't want to overload upgrade just for fun or because tags might be nice. Ugrade as it is requires certain things that are not provided in the actual tree. I can provide it using a branch and that does not hurt anyone and does not need any adaption on the current buildenv. If we can provide the same functionality your way, I am fine. > > So, if we will have tags in repo, to access to right version of packages > we should use > https://sourceforge.net/p/leaf/packages/ci/5.1-stable/tree/5_1/ as base No,. because 5_1 is not a good base. It does not refer to anything in a running kernel, so it requires too much guessing on a script level. I am already guessing too much IMHO. If you want to use such a method then you will have to provide a full URL in a file. That of course is possible. > URL (5.1-stable commit in 5_1). Or even for manual downgrade due to > regression - something like > https://sourceforge.net/p/leaf/packages/ci/5.1.1/tree/5_1/ Why should we go such an inconvenient way. The 5_1 is IMHO a bad convention and is already contained in the 5.1.1. This is redundant information. >> >>> Or we can use symlinks that points to right place. >> Difficult unless we use Yves' git store module, which I failed to >> understand. > Why? Git symlik should be accessed like regular dir from the web. I don't care what method is used. Branches are convenient for me, if you have something better. please go for it. 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
