On 9/7/06, paul kölle <[EMAIL PROTECTED]> wrote:
Andy Dustman schrieb:
> SYNC="rsync://rsync.gentoo.org/gentoo-releases"
> RELEASE="2006.1"
> RELEASE_OVERLAYS="updates security"
>
> Doing a emerge --sync would then perform the following:
>
> * rsync://rsync.gentoo.org/gentoo-releases/2006.1 to $PORTDIR
> * rsync://rsync.gentoo.org/gentoo-releases/2006.1-updates to
> $PORTDIR-updates
> * rsync://rsync.gentoo.org/gentoo-releases/2006.1-security to
> $PORTDIR-security
>
> $PORTDIR-updates and $PORTDIR-security could then be treated as
> implicit PORTDIR_OVERLAYs. SYNC could be overridden in /etc/make.conf
> as it is now. If you wanted only security updates, then you could set
> RELEASE_OVERLAYS="security" in make.conf.
Disclaimer: I'm not trying to shoot you down, just ask some questions...
>
> This is now three trees to sync against
From which two don't exist (yet). You need to specify how they should be
generated and maintained.
> instead of one, but the
> important feature is that the primary tree is now static data,
could be the snapshot coming with the release...
Yes, it would be, ideally. I've left it as being a sync-able tree
above, but it could be a drop-in tarball.
> once it
> is done as a final release, so there is only the timestamp check; and
> the other two trees should be relatively small. Obsolete ebuilds need
> only be removed when there is a new release, and this happens in a
> different tree. Potentially, only packages with at least one stable
> arch flag could go in updates; anything that is all ~arch or masked
> could go into a separate testing overlay.
If you dont set ~ARCH why are you concerned about ~arch ebuilds?
I'm not especially worried about ~arch builds. Breaking out testing
ebuilds is optional, but since they tend to change a lot more than
stable (arch) builds, not having to sync them is a win for users who
don't want or need them.
If this
is about space saving or cutting down sync time/resources you need to
explain how the "security" and "updates" branches would be maintained
and integrated.
Some sort of management tool is going to be needed on the gentoo.org
side of things to make all this possible. We already have GLSAs, so
ebuild that implements a GLSA fix should go into security. Any other
changes from the baseline release would go into updates. Actually,
there are a couple different scenarios:
1) baseline and updates: baseline is static data from initial release,
updates contains any changed files.
2) baseline, updates, and security: As #1, except builds with security
updates go into security.
3) baseline, testing, updates, security: As #2, except any
testing-only ebuilds go into testing.
4) Variation on : Keep the existing single tree with everything in
addition to having release-specific trees.
packages.gentoo.org has some means of tracking new packages as they
are released, so the release trees could be updated automatically by
tieing into this process.
--
This message has been scanned for memes and
dangerous content by MindScanner, and is
believed to be unclean.
--
[email protected] mailing list
