On 2016-02-05 12:32, Jacco Ligthart wrote:
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.
Allright, I'll move the current el6 out of the way, re-sign el6-devel
contents and distribute the packages between repositories as discussed.
Hopefully this weekend.
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.
OK, point releases it is.
Gordan
_______________________________________________
users mailing list
[email protected]
https://lists.redsleeve.org/mailman/listinfo/users
