On 2015-06-01 19:58, Jacco Ligthart wrote:
On 06/01/2015 08:28 PM, Gordan Bobic wrote:
On 2015-06-01 19:00, Jacco Ligthart wrote:
On 06/01/15 13:59, Gordan Bobic wrote:
Jacco,
Is your final EL7 build process complete? For the release I need to
sign
all the packages and put together an updated redsleeve-release
package.
That means adjusting the directory structures somewhat, and I think
it
would be a good idea to instante a temporary goal post freeze before
doing that. :)
It mostly is. There are 8 packages still to do. 4 are waiting on the
redsleeve ntp pool (they are build, just waiting for the hostnames to
come through). And 4 are branding/logo's etc related. I saw that you
did
one of them, which I'll put in there later today.
On the directory layout, It was quite obvious (to me) when I made it,
but I can see why it's not obvious to others :)
You misunderstood what I meant. It wasn't that it wasn't obvious, it
was
that it needs:
1) Moving to a different path so that signed packages can go into the
/pub/el7/ path
I think I did understand, but just decided on the long explanation
anyway :)
2) Pruning out duplicates and unifying the repositories. Any
objections
to merging the base and updates into a single large rolling
repository?
I think that would provide for a cleaner setup. We can then have a
separate
updates repository to keep the metadata on it small, and periodically
merge
the contents of it back into the base repository. It would mean the
base
is mostly static (reduces the amount of re-downloading of the large
metadata) and keep the updates repository reasonably small most of the
time.
So:
el7-base: Rolling everything, updated with contents of el7-update
periodically
el7-update: The recently updated packages
el7-epel: Exactly what it says on the tin.
el7-extra: All the extra stuff that we found useful but either doesn't
exist at all in any of the above, or the version exceeds what is
availble
in the other repositories.
el7-$device: Extra device specific repositories, e.g. custom kernels
and
drivers for various devices.
Thoughts?
yes, two:
1) I'd say keep inline with upstream dot versions. so if 7.2 comes
along, that's the right time to create a new base repo. One of the
reasons for this is that at these points also packages can disappear.
maybe something like el7.1-base, el7.2-base, etc and a symlink from
el7-base to the latest.
Hmm, interesting, but a good point.
Perhaps then also have a separate "rolling" release that switches the
user to the rolling repository. I know that one thing that regularly
annoys me is that Scientific Linux, for example, gets stuck with a
minor release, and then stops updating unless an update gets sent to
the old minor release. From the usability and security point of view
I'd much rather have the rolling release.
It also means we don't have to worry as much about keeping in line
with upstream partial packports into earlier minor releases.
2) maybe keep *our* extras and *upstream* extras separate.
An excellent point. What should we call our extra that is not the
upstream extra?
Gordan
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
