Am 30.03.2015 um 23:24 schrieb Andrew: > 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: >> ... ... >>> 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.
We can store packed and unpacked modules on the server. On the target machine this is no option, at least not on all of them. There is simply not enough storage on small media and these exist. I have one sitting in front of me. .. >>> 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. No, I was just not aware of any moddb info. It is used nowhere so just about like the human appendix.... No known use. I will copy it to my moddb file. > 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). Right, I was only thinking about moddb.version and help. >> >>>>>>> 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. Yes, but this leaves the structure unmodified. As I said, I did not want to touch the existing structure and a branch is a convenient method to avoid that. >> ... > 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). Oh right now upgrade supports the following options --stable --latest --release x.y.z This should be ample for such a simple function. > 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) Right, that is what upgrade does right now. >>> 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. This can be achieved, but of course requires the correct tree on the server. > 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. That is true, it requires two clicks. It is not true though that you can find all releases easily right now, and to tell you the truth, I was not even aware of a packages repository until a few days ago and I am using LEAF for more than ten years. >>>>> 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. We should only have master and a few recent branches anyway. To keep the old cruft may be fun for an archologist, not really for me. I don't want to keep branches, for me they are just a tool. If you can arrange a tree structure which meets the current needs or which one can easily adapt to, right... I don't really care. I tried to analyze my own requirements. - I want a tool to upgrade easily - It should require as little user intervention as possible - it should provide some logging (syslog) When I started I did not even care for a 'latest' branch, all I was looking for was 'stable', which for me is the currently latest stable release. Now if you look at the branches I created 5.1.3 5.1.4-rc1 Those are not just arbitrary release numbers, they hold exactly the data for these releases. 5.1.3 correspods to 5_1 5.1.4-rc1 corresponds to stable-new (this was the test directory stable, it blocked my file name stable) I used the files 'stable' and 'latest' to point to current releases without relying on links, as this was presented as a nono on this list. So I don't really care if we use branches or tags or whatever gimmick may be hidden inside git. As long as the necessary data is provided I am fine. 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
