| 1 |
On 9/7/06, paul kölle <pkoelle@×××××.com> wrote: |
| 2 |
> Andy Dustman schrieb: |
| 3 |
> > SYNC="rsync://rsync.gentoo.org/gentoo-releases" |
| 4 |
> > RELEASE="2006.1" |
| 5 |
> > RELEASE_OVERLAYS="updates security" |
| 6 |
> > |
| 7 |
> > Doing a emerge --sync would then perform the following: |
| 8 |
> > |
| 9 |
> > * rsync://rsync.gentoo.org/gentoo-releases/2006.1 to $PORTDIR |
| 10 |
> > * rsync://rsync.gentoo.org/gentoo-releases/2006.1-updates to |
| 11 |
> > $PORTDIR-updates |
| 12 |
> > * rsync://rsync.gentoo.org/gentoo-releases/2006.1-security to |
| 13 |
> > $PORTDIR-security |
| 14 |
> > |
| 15 |
> > $PORTDIR-updates and $PORTDIR-security could then be treated as |
| 16 |
> > implicit PORTDIR_OVERLAYs. SYNC could be overridden in /etc/make.conf |
| 17 |
> > as it is now. If you wanted only security updates, then you could set |
| 18 |
> > RELEASE_OVERLAYS="security" in make.conf. |
| 19 |
> Disclaimer: I'm not trying to shoot you down, just ask some questions... |
| 20 |
> |
| 21 |
> > |
| 22 |
> > This is now three trees to sync against |
| 23 |
> From which two don't exist (yet). You need to specify how they should be |
| 24 |
> generated and maintained. |
| 25 |
> > instead of one, but the |
| 26 |
> > important feature is that the primary tree is now static data, |
| 27 |
> could be the snapshot coming with the release... |
| 28 |
|
| 29 |
Yes, it would be, ideally. I've left it as being a sync-able tree |
| 30 |
above, but it could be a drop-in tarball. |
| 31 |
|
| 32 |
> > once it |
| 33 |
> > is done as a final release, so there is only the timestamp check; and |
| 34 |
> > the other two trees should be relatively small. Obsolete ebuilds need |
| 35 |
> > only be removed when there is a new release, and this happens in a |
| 36 |
> > different tree. Potentially, only packages with at least one stable |
| 37 |
> > arch flag could go in updates; anything that is all ~arch or masked |
| 38 |
> > could go into a separate testing overlay. |
| 39 |
> If you dont set ~ARCH why are you concerned about ~arch ebuilds? |
| 40 |
|
| 41 |
I'm not especially worried about ~arch builds. Breaking out testing |
| 42 |
ebuilds is optional, but since they tend to change a lot more than |
| 43 |
stable (arch) builds, not having to sync them is a win for users who |
| 44 |
don't want or need them. |
| 45 |
|
| 46 |
> If this |
| 47 |
> is about space saving or cutting down sync time/resources you need to |
| 48 |
> explain how the "security" and "updates" branches would be maintained |
| 49 |
> and integrated. |
| 50 |
|
| 51 |
Some sort of management tool is going to be needed on the gentoo.org |
| 52 |
side of things to make all this possible. We already have GLSAs, so |
| 53 |
ebuild that implements a GLSA fix should go into security. Any other |
| 54 |
changes from the baseline release would go into updates. Actually, |
| 55 |
there are a couple different scenarios: |
| 56 |
|
| 57 |
1) baseline and updates: baseline is static data from initial release, |
| 58 |
updates contains any changed files. |
| 59 |
|
| 60 |
2) baseline, updates, and security: As #1, except builds with security |
| 61 |
updates go into security. |
| 62 |
|
| 63 |
3) baseline, testing, updates, security: As #2, except any |
| 64 |
testing-only ebuilds go into testing. |
| 65 |
|
| 66 |
4) Variation on : Keep the existing single tree with everything in |
| 67 |
addition to having release-specific trees. |
| 68 |
|
| 69 |
packages.gentoo.org has some means of tracking new packages as they |
| 70 |
are released, so the release trees could be updated automatically by |
| 71 |
tieing into this process. |
| 72 |
-- |
| 73 |
This message has been scanned for memes and |
| 74 |
dangerous content by MindScanner, and is |
| 75 |
believed to be unclean. |
| 76 |
|
| 77 |
-- |
| 78 |
gentoo-server@g.o mailing list |
Archives