>>> 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. I meant to do that "CentOS"-style. Point all .repo things to "el7-base" and by default everybody gets the new repo if we switch the symlink.
> > 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? perhaps tie this in with the earlier discussion about el7-repo and call everything we do el7-redsleeve ? I fear creativity runs a bit low here :) Jacco _______________________________________________ users mailing list [email protected] http://lists.redsleeve.org/mailman/listinfo/users
