30.03.2015 23:40, Erich Titl пишет: > 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. Right. Except spent time on slow PCs (but I think that really slow ones like Geode/i486SLC clones like Advantech one will not require modules on storage). From other side, we may store both packed and unpacked modules. >>> ... >>>>> 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. Packaging trouble? This may be fixed easily. In any case, file is exist in tree. About .dep in moddb - it may be a bad idea. And depmod from it should be removed IMHO (it's useless - it is re-created at booting). > >>>>>> 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. You may just add tags to some commits in repo. Tag can be added to any commit, incl. old one. > >>> 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. We may modify file structure in future commits, adding packages list (with deps), unpacked modules tarball and so on.
>> 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. You'll have a tag (5.1-stable) that points to some commit with stable version (5.1.3, 5.1.4, 5.1.5 and so on). You'll have a choice in config, what branch you want to track (5.1 or 5.2). And you'll have a choice in config, what fresh releases you want to obtain (stable or development). For cross-branch upgrade - you should upgrade all packages that are present on storage (because gcc/uclibc may be upgraded and this may cause a lot of binary compat issues - during upgrade I successfully ran some apps from 5.1 on 4.x branch, like wget, but not all worked ok) >> 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. In that way all will be done in one repo, in one branch. I'm not sure that separate packages branch per each LEAF branch is better than pushing all into master branch and separating versions by tags. Advantage of 'all in one branch' storage - anybody can find/grab all current releases in one click. >>>> 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. It seems that it'll be better to place each release to new directory with symlink in master for it, or to use git tags when using single directory. But using new branch for each minor release, with 'stable' and 'development' files that contain branch names IMHO is overkill and looks dirty. After couple of years we'll have tens of branches, and each of them will have single commit. > cheers > > ET > > > > ------------------------------------------------------------------------------ > 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
