Re: Linux 2.0.36 in slink?
On Sat, Dec 26, 1998 at 02:15:13PM -0800, Oscar Levi wrote:
> It is clear that we don't understand each other. Let's take another
> tack and identify what problems we are trying to solve.
>
> 1) Just before release, it takes a long time for package updates to
> make their way into the mirrored archives so that we can test
> them. This is due to the appropriate caution of the release
> manager(s).
Yes. The proposal eliminates this by causing nothing to be uploaded to
pre-release (now called frozen and not always actually even there)
Packages are available the very next day after dinstall does its thing or
for new packages after the archive managers (not the release manager as
now, difference being there are half a dozen archive managers) make sure
the packages dinstall does not know about are checked real fast and
added as now---updates to unstable happen very fast because dinstall does
most things and what dinstall doesn't the archive managers do quickly.
> 2) Performing incremental updates to a running system is desirable
> for the sake of testing. Packages will be upgraded and
> downgraded in order to isolate problems or return a broken system
> to a working state.
Under the proposed change, most people who don't want the bleeding edge
would run pre-release, many of them with a few (or a great many,
depending) packages from unstable. The way I see this implemented best
would be with apt and having distribution tags. Instead of a list of
sources for package files period, it's given a list of dists and the
sources to package files for that dist. You then have a setting for
which dists you upgrade packages in automatically. Most of us would have
"stable, pre-release" in that, though some of us might have something
probably like "stable, pre-release, local, kde, mozilla-cvs-weekly" for
example.
The other dists' package files are gotten but are not automatically
upgraded to. Then you might do something with either GUI or console
tools like "apt-get --dist unstable mypackage" and it would then tell you
what it would need to get from each dist in order to install your request
noting the dists the packages it wants are in. Not as good as having
multiple versions of a package in unstable, but a hell of a lot better
than we have now to be sure and the kinds of changes necessary to make
that work will be a step closer to being able to have multiple package
versions in a dist.
> In the proposal that I originally read, we introduce a prerelease
> distribution with links and packages similar to our current
> distributions. Without other changes, this renaming alone forces us
> to install 'prerelease', test it, and then decide if packages from it
> can be moved to an 'accepted' tree.
pre-release _IS_ th "accepted" tree. It replaces frozen.
> If the 'prerelease' proposal helps us solve the above problems then so
> be it. What I read did not explain how these problems are solved.
You missed the discussion we had back around I think april.
--
NO ONE expects the Spanish Inquisition!
Reply to: