On 02/05/2016 12:22 PM, Gordan Bobic wrote: > On 2016-02-05 11:00, Jacco Ligthart wrote: >>>> OK, I think I'm complete with 6.7 updates till today. It should all be >>>> on the mirrors soon. >>>> >>>> small guide to my strange file/folder layout: >>>> there are a couple of folders: >>>> base - everything originally in RS6 base (build by Gordan) >>>> update - everything originally in RS6 update (build by Gordan) >>>> updates-testing - everything originally in RS6 updates-testing (build >>>> and signed by me) >>>> new - everything new in RS6.7 (build and signed by me) >>>> old - stuff that should have been replace by a newer version, but I >>>> could not get the newer version to build >>> >>> Are these mutually deduplicated? As in, is there only one version of >>> each package between all of the above repositories? If so, might I >>> suggest putting all of them in base, and putting any future new >>> packages in update? >> yes, it is deduplicated. >> I was indeed hoping that you would create one release out of it :) > > I will, but I think it makes sense to try to make both the release > and testing repositories have the same structure.
Ack. maybe It is easiest to first do the release proper and then adjust testing (if needed) to have the same stucture. Lead, and I will follow :) > >> btw, I just found out that I also build all the updates from the >> fastrack. I could not distinguish them from the normal updates on the >> redhat ftp site. > > Sounds good. :-) > >>> What I have in mind is something along the lines of having the >>> redsleeve-testing repository looking the same as the release >>> one, only living under /pub/el6-devel/ on the server. I think >>> that would significantly tidy things up and make the layout more >>> intuitive. >> >> Sounds good. >> I would also be interested in where to place extra, upstream-extra and >> board specific packages. > > What is upstream-extra? Isn't that a CentOS thing? > > How about: > > upstream-extra -> extra > our extra -> rs-extra > board stuff -> rs-$boardname > > ? Also fine. For el7, we also had this discussion. When building 7.2 I found it made sense to have two extras (one upstream and one ours). I just named them something, but I don't care what the exact name is. > >> My suggestion would be to have upstream-extra within the release tree >> (6.7 in this case) > > Hmm... I think having separate 6.x releases (and separate trees) is only > useful if all the packages end up getting rebuilt from scratch. If we > are just grabbing old packages and pushing them over, then it would make > more sense to only maintain the 6 (rolling) release, ignoring point > releases as far as repositories are concerned. > >> normally 'our' extras and board specific rpms are not tied to a specific >> release, so they could be outside the release tree. >> something like this: >> el6 >> ├── epel >> ├── extra >> ├── odroid >> ├── raspberry >> ├── Redsleeve6.7 >> │ ├── base >> │ ├── update >> │ └── upstream-extra >> └── Redsleeve6.8 >> ├── base >> ├── update >> └── upstream-extra >> el6-devel/ >> ├── epel-testing >> ├── extra-testing >> ├── odroid-testing >> ├── raspberry-testing >> └── Redsleeve6.7 >> └── update-testing > > > See above. Is there an advantage to having separate releases over keeping > just a single rolling release? Even if we keep a single rolling release > we can still occasionally clean up and merge things from updates to > base and deduplicate. That part could even broadly coincide with point > releases. > > I don't have any objections to keeping separate releases per se, I > would just prefer to keep things as simple as possible, and there is > precedent for rolling repositories in other EL rebuild projects, albeit > not to the complete exclusion if point releases. At the point releases they sometimes introduce incompatible library versions. I find it difficult to build that as rolling. For me it is easier to break the previous release down to 'things that are there to stay' and then add newly build stuff. We have seen this going wrong before with the 'evolution-data-server'. AFAIK, nobody rebuilds old packages at the point release. I am actually quite sure that it would break. At 7.1 time there were a couple of packages that would only build with the 7.0 version of java, not to mention builds that break because of expired certificates. another point is that at the point release packages are also removed. that would not work for rolling and lastly, we tend to have discussions about what to include in the release if something does not pass the tests. firefox for 6.7 as an example and gnome or another. Somehow I think that this will work better if we follow the point release. just remembered the really last point :), IIRC point releases were the popular vote on the mailinglist when I asked this last April. Jacco _______________________________________________ users mailing list [email protected] https://lists.redsleeve.org/mailman/listinfo/users
