Subject: rfc: bulk-build mail list and binary packages
To: None <tech-pkg@netbsd.org>
From: David Brownlee <abs@netbsd.org>
List: tech-pkg
Date: 06/15/2001 16:01:19
Updated proposal
Problems
^^^^^^^^
i) Binary packages are not available for many platforms,
and building of such is not coordinated.
ii) Binary packages for a given arch/osrev on ftp.netbsd.org
can be built against different depends, or depends
updated, resulting in mismatched packages which will
not install.
iii) New versions of binary packages are uploaded which
will not install against a user's existing set of
installed depends.
The proposal attempts to cover i) and ii). It does not
directly address iii), though having a consistent set of
binary packages on ftp.netbsd.org will obviously mitigate
somewhat. (*)
Proposal
^^^^^^^^
- Create a 'bulk-package' list. Developers signup to
handle any given arch/osrev. When they can no longer
handle that arch/osrev they pass the 'token' back to
the list for someone else to pick up.
- When uploading packages developers will upload/rsync
their entire set of bulk built packages, and delete
any other packages for that arch/osrev on ftp.netbsd.org
- When taking over an arch/osrev combination a developer
will either start bulk building from scratch, or
download the current set of binary packages from
ftp.netbsd.org to 'pre seed' their build process
(most useful for slower architectures).
- Any developer can upload updated/new/security-fix
packages to ftp.netbsd.org, but they _must_ be built
against the set of binary packages already present
for that os/arch.
- Developers should run the latest minor release, or
(recommended) track the release branch.
(*) Addressing iii) either involves freezing binary packages
at tagged values, or having multiple binary package
trees per arch/osrev. The former reduces significantly
reduces the utility of the binary packages, and the
latter is not worth considering until we can get _one_
consistent tree per arch/osrev.
--
David/absolute -- www.netbsd.org: No hype required --