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.
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
?
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.
Gordan
_______________________________________________
users mailing list
[email protected]
https://lists.redsleeve.org/mailman/listinfo/users
